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FROM THE EDITOR 


A Tale of Iwo 
Giants... 


nce upon a time there were 
two electronic giants, strug- 
gling for dominance in the 
Valley of Silicon. They were unfriendly 
rivals; each making similar products, 
each holding on to an equal share of 
the marketplace, each “leapfrogging” 
the other with new designs. When 
Giant X introduced a new MP3 player, 
for example, Giant Y would soon 
introduce one with more features ata 
lower cost. And, because they used 
the same basic components, design 
methods, and manufacturing process- 
es, they each remained “competitive,” 
but their profit margins were atro- 
cious. The competition was fierce; life 
was uncertain; no one smiled. 





Then one bright morning (after 
reading a particularly insightful edito- 
rial in the Xcell Journal), Giant X 
awoke from a vivid dream in which he 
saw the future. He thought “What if | 
could create new products that never 
had to be replaced? What if | could sell 
customized features, options, and 
complete new designs, and download 
them to my customers, anywhere in 
the world, over the Internet? That's 
like manufacturing something once, 
but selling it many times over!” He 
knew it was the next “big thing.” He 
grinned a big toothy grin. 


Giant X began designing all his 
new products using the latest pro- 
grammable logic technology (from 


Xilinx of course). The new FPGAS and 
CPLDs were amazing; they were 
dense, fast, inexpensive, and required 
little power; they were easy to use 
because the development tools were 
fast and efficient, and there was a lot 
of Intellectual Property (cores) avail- 
able to make his life easy. Plus, with 
Xilinx technology, he could provide an 
Internet interface to all of his products 
and easily download almost any new 
design the market demanded. “Simply 
brilliant!” remarked the press. 
“Amazing!” remarked his customers. 
“Highly profitable!” said his sharehold- 
ers. Everyone grinned big toothy grins, 
except Giant Y of course. 


It wasn’t long before Giant Y’s 
market share began to nosedive. In a 
panic he worked night and day to keep 
up with the almost daily introduction 
of new products, features, and options 
from Giant X; but he could no longer 
compete using his old technology. 
Greatly embarrassed, Giant Y quietly 
packed his bags and left town; he was 
never heard from again. 


The moral of this story is clear. 
Low-cost, high-performance pro- 
grammable logic, reprogrammed 
remotely, is the obvious next step in 
the evolution of logic design—the 
advantages are overwhelming. 


This issue of Xcell will show you 
some of our latest, low-cost, remotely- 
reprogrammable giant killers#. 


For A FREE 
Subscription 
To The Xcell 

Journal 





COLUMN 4 


The year 2000 promises to bring even 
faster growth, with many new applica- 
tions, because our technology has 
passed a key milestone. 


LOVER STORY 5 
Spartan™ FPGAS are experiencing 


tremendous growth due to their inherent 
advantages over ASICs. 


PRODUCT INFORMATION 26 


New CoolRunner devices are ideal for 
low-power, high-performance applica- 
tions. 


(PPLICATIONS 35 


CoolRunner™ CPLDs are used as the 
main controller for an MP3 player. (Also 
see a Spartan-Il MP3 design on page 15.) 


OFTWARE 52 


This HDL design methodology can help 
you use the largest Virtex™ FPGAs with 
a minimum amount of time spent on 
synthesis, simulation, and verification. 


WWwW.XIIINX.cCOom 


E-mail your request to: literature@xilinx.com, 
please be sure to include: 


1. Your full name and 4. Your e-mail address 


mailing address 5. Is this new subscription 


2. Your title or a subscription renewal? 
3. The name of your company 


View from the Top 


aMit-msaclele-liitiit-le)(-m mele lem tla <-15 


Cover Story 


The New Spartan-II FPGA Family, 
Kiss Your ASIC Good-bye 


Spartan FPGAs 


New Spartan-II FPGA Family - 
Ideal for ASSP Replacement... . 


The Spartan-II Design Flow Simple 
Powerful, and Efficient 


How to Create an MP3 Player, 
Using a Spartan-I!I FPGAs 


Inverse Multiplexing for 
ATM (IMA) 


1D] Om Oro} aluge)i(-lamvel(eittolatmerjiare| 
Spartan-IIl FPGAs 


Low Power Benefits of 
Spartan-XL Family 


CoolRunner CPLDs 


The New XPLA3 CPLD Family - 
The Best CoolRunner Family Yet . 


CoolRunner Power 
jaf ait hee) am Mele) | 


Implementing an I’?C Bus Controlle 
in a CoolRunner CPLD 


How to Create an MP3 Player 
Using a CoolRunner CPLD 


Applications 


Get the Best Registered I/O 
Timing with Virtex-E FPGAs 


UT ate l=Teie-Tarelialemt-140) om lare| 
Hold Times 


HDL Coding for Pseudo-random 
Coy f-X=m CL=\al-1a-1 ke) a 


Post Synthesis Verification 
for Virtex FPGAs 


Using the ModelSim FPGA 
Library Manager 


FPGA System Simulation 
and Synthesis 


Columns/ Reference 
Industry Analyst Column 
Q&A Column 


Trade Show Column 


Software Availability Guide 





The Programmable Logic Market 


Grew significantly 


..and the year 2000 promises to bring even faster growth, with many new 
applications, because our technology has passed a key milestone. 


by Wim Roelandts, President and CEO, Xilinx 





year, and is well on its way to 
becoming the development technol- 


rogrammable logic technol- 
ogy has made many signifi- 
cant advances over the last 





ogy of choice for most applications. 

Xilinx is growing very quickly as a result. Here 
are some of the highlights of our phenomenal 
growth in 1999: 


The Xilinx stock split twice, once in March 
and once in December. This helped give us a 
market capitalization of about $14.5 billion, 
making us second only to Intel among semi- 
conductor suppliers here in Silicon Valley. 
This gives us an increased ability to fund new 
research and bring advanced new technolo- 
gies to market. 


Xilinx was placed on the Merrill Lynch “Top 
10 Tech” list (replacing Intel), indicating their 
highest confidence in our continued strength, 
and in the growth potential of the overall pro- 
grammable logic market. 


Xilinx was added to the S&P 500 index, 
another indication of the market’s confidence 
in Our Ongoing strength. 


We built a new 180,000 sq. ft. building on our 
San Jose campus to handle our recent growth, 
and began the development of a new 130,000 
sq. ft. facility in Longmont Colorado. 

Groundbreaking is scheduled for March 2000. 


We expect our revenues to approach $1 bil- 
lion by the end of our fiscal year (March 
2000), 50% higher than last year. 


It was a very good year for Xilinx; our invest- 
ments in new device and software technologies 
have paid huge dividends, and our products have 
consistently extended the previous limits of den- 
sity and performance while significantly reducing 
prices. 


FPGAS were once used primarily in high-end, 
low-volume equipment which consists of about 
25% of the total marketplace. This was due in 
part to the relatively high cost of FPGAs (as com- 
pared to custom devices). To serve the other 75% 
of the marketplace, our research showed us that 
we would need to produce high-performance, 
full-featured FPGAs with at least 100K gates, and 
sell those devices, in volume, for less than 
$10.00. With the introduction of our new 
Spartan-Il family, that’s exactly what we’ve done. 
This is a significant milestone that will bring 
many unique new applications. 


The growth of the programmable logic mar- 
ketplace is important to you because these 
devices allow you to get your products to market 
six to nine months faster than with ASICs, and 
they allow you to upgrade your equipment over 
any network after it’s installed at your cus- 
tomers’ locations. We here at Xilinx will contin- 
ue our innovation and this will lead to higher 
densities, higher performance, more features, a 
wider selection of intellectual property (cores), 
and lower prices. We intend to keep making your 
job easier while adding value to your products. # 
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by Jay Aggarwal, Product Marketing Manager 
Spartan Series, Xilinx, jay.aggarwalaxilinx.com 


he Spartan Series FPGAs, introduced by 

Xilinx in January 1998, offer a very 

attractive alternative to ASICs for your 
high volume, low cost applications. The Spartan 
families are designed to penetrate markets that 
were once dominated by ASICs. These include 
digital modems, printers, faxes, portable audio 
players (such as MP3), set-top boxes, and POS 
terminals. The Spartan Series is the first FPGA 
family to provide a complete and compelling mix 
of advanced features, low prices, high perfor- 
mance, and powerful development tools; the key 
ingredients required by ASIC designers. Now, the 
new Spartan-ll™ FPGA family sets a new stan- 
dard for low cost, and high performance. 


The Spartan-Il Family 


Fabricated on a leading 0.18 um, six-layer metal 
process, the Spartan-Il family uses the most 
advanced process technologies available today. 
The family’s core voltage operation is 2.5V, yet it 
incorporates unique I/ O technology that allows 
both 3.3V and 5V I/O operation. 





















































Device XC2S15 XC2S30 XC2S50 XC2S100 XC2S150 
System Gates 15K 30K 50K 100K 150K 
Logic Cells 432 972 1728 2700 3888 
Block RAMBits 16,384 24,576 32,768 40,960 49,152 
Block RAMBlocks 4 6 8 10 12 
DLLs 4 4 4 4 4 
I/O Standards Supported 17 17 17 17 17 
Max I/O 86 132 176 196 260 
Packages 14xl4mm _ —~‘VQ100 VQ100 

20x20mm 10144 TQ144 TQ144 TQ144 

12xl2mm_ _— S144 CS144 

28x28mm PQ208 PQ208 PQ208 PQ208 

17x17mm FG256 FG256 FG256 

23x23mm FG456 FG456 


Table 1 - Integrated features. 


The Spartan-ll family includes new system- 
level features such as delay lock loops (DLLs), 
BlockRAM™, distributed RAM, multiple I/O stan- 
dards, ultra-high performance, and power man- 
agement. All of the features found in ASICs and 
ASSP devices are now available in the Spartan-I| 
family at very attractive prices. Spartan-II FPGAs 
also provide an impressive array of highly com- 
plex cores (intellectual property) enabling you to 
further leverage the time-to-market benefits 
offered by programmable logic. 


Memory 


On-chip memory ts vital to most designs, from 
buffering data between two dissimilar buses to 





Select io 


Block Memory 


Power Management 


oo Ribep Mode Con figaration 


Register Site Mattained 
Figure 1 - Spartan-ll family architecture. 


providing storage locations of constants for high 
performance DSP functions. The Spartan-I| fami- 
ly provides you with maximum memory flexibill- 


ty. 


Xilinx pioneered the capability of distributed 
memory (also found on Spartan and Spartan- XL 
families), which efficiently implements 
wide/ shallow FIFOs or scratch pads memories. 
The family also incorporates BlockKRAM (in 
blocks of 4Kbits) which efficiently implement 
memory for deep FIFOs, single port RAM, and 
True Dual Port RAMs as shown in Figure 2. 
Unlike competing two-port architectures, Xilinx 
provides true dual port RAM operation, for high- 
Speed read and write operation. 


Delay Locked Loops 


DLLs perform the same tasks as traditional 
phase lock loops (PLLS) but are more robust and 


Two-Po 





Figure 2 - Spartan-ll family dual port memory. 
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are less susceptible to noise interference, a 
common problem with PLLs. The Spartan- 
Il DLLs allow you to multiply or divide the 
incoming clock on chip, as well as drive 
multiple clocks on the board. The DLL fea- 
ture also allows you to de-skew the clock 
on chip, ensuring all nodes on the device 
are synchronized while providing mini- 
mum set-up and hold times. 


With four DLLs per device, the Spartan- 

Il family provides a sufficient number of 
DLLs with which you can perform multiple func- 
tions. For example, one DLL may be used to de- 
Skew the clock on chip, one for multiplying the 
clock for accelerated performance on chip, two 
DLLs to drive clocks to various devices on the 
board—all at the same time. A single crystal 
oscillator and a Spartan-I|l device may provide all 
the clock management you need for your board 
design. 


Selectl/O™ 


The Spartan-ll family supports most of the popu- 
lar and demanding I/ O standards, including 
those that are optimized for high-speed memory 
interfaces. The new input/ output standards that 
are supported, include SSTL, HSTL, AGP, GTL, 
GTL+, and PCI. The integration of these stan- 
dards into the Spartan-II family now allow the 
elimination of costly bus transceivers that take 
up valuable board space. 


The I/ Os for the Spartan-lII family are 5V and 
3.3V tolerant for interfacing with older genera- 
tion technology on the board. This is a signifi- 
cant advantage for the family because competing 
architectures are unable to support 5V operation. 


Support for high-speed interfaces significant- 
ly increases performance over the Spartan (80 
MHz) and Spartan-XL (100 MHz) families, to a 
blazing 200 MHz. 


Power Management 


Power consumption is an important 
issue, especially for portable and 
hand-held designs. The Spartan-ll 
family extends power management 
features that were first established 
with the Spartan-XL family, which 
provides a power down pin on each 
device. Once activated, the device 
goes into a low power sleep mode In 
which power consumption is signifi- 
cantly reduced. When the pin is de- 
asserted, the device comes back into 
full power mode and retains its con- 
figuration as well as register states. 


SOTL=2 Translations 


Cozi 


Pricing 


The Spartan-ll family has been created from the 
ground-up, in keeping with the Spartan Series 
philosophy, to provide industry-leading features, 
density, and performance at price points that 
match or beat ASICs and ASSP devices. The fam- 
ily has been able to achieve a milestone, long 
sought after and promised by the programmable 
logic industry but now only realized by the 
Spartan-Il family: 100,000 gates for $10.00USD. 


Below is a complete listing of high volume 
prices for the Spartan-Il family at introduction. 


Xilinx 


Spartan Il 


Product 
XC2S15 
XC2S30 
XC2S50 
XC2S100 $ 9.95 
XC2S150 $12.95 


* 250K units, a resale price, slowest speed/cheapest package 


High Volume Price* 
$ 3.95 
$4.95 
$7.95 




















Table 2 - Spartan-ll family pricing. 
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Figure 3 - Spartan-ll value. 


An Example of Spartan-Il Value 


The board diagram in Figure 3 illustrates how 
you can integrate many different functions into a 
Spartan-Il FPGA to achieve significant cost sav- 
ings. This example design includes a PCI mas- 
ter/ target controller, some HSTL translators, a 
cache controller, SSTL-3 translators for SDRAM, 
a backplane interface, some glue logic, and the 
clock management device. All of these functions 
can be integrated into the XC2S100 Spartan-ll 
device which costs just $10.00, almost two-thirds 
less than the discrete solution, with room to 
Spare for more logic. The Spartan-lIl solution also 
uses less board real estate, requires less power, 
and provides higher reliability. 


Conclusion 


The Spartan-ll family offers you the most cost- 
effective and flexible solution, enabling the 
fastest time-to-market with the lowest possible 
risk. # 


For more information regarding how the Spartan-ll family addresses 
traditional ASIC and ASSP designs, please see the article on page 8. 





The Spartan-II family, combined with a vast portfolio of soft IP, is the first 
programmable logic solution to effectively penetrate the ASSP marketplace. 


by Krishna Rangasayee, Manager, Strategic App 
Xilinx, krishna@xilinx.com 


partan-I| FPGAs offer more than 100,000 sys- 
tem gates at under $10.00 and are the most 





cost-effective PLD solution ever offered. They 
build on the capabilities of the very successful Virtex™ 
FPGA family and include all of the Virtex features, 
including Selectl/O™, BlockKRAM™, Distributed RAM, 
and DLLs, with clock speeds up to 200 MHz. 


PLDs Penetrating the ASSP Market 


In the past, programmable logic devices had limited 
success in penetrating the ASSP market because they 
could not compete in the key areas of density, fea- 
tures, performance, and cost. However, the Spartan 
family competes very well due to the use of advanced 
process technologies. This approach has allowed 
Xilinx to significantly reduce die sizes, and therefore 
reduce the cost of the overall solution. This rapid pro- 
cess transition allows the Spartan family to compete 
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Figure 1 - PLD evolution - addressing the ASSP marketplace. 
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lications, 


with ASICs and ASSPs, and has opened up many new 
markets for PLDs. 


Advantages of a Programmable ASSP 


A programmable ASSP like the Spartan-Il family offers 
Significant advantages over a stand-alone ASSP. The 
advantages are broadly classified under the following 
areas: 


e The value of programmable ASSPs. 

e Accommodating specification changes. 
e Testing and verification. 

e Xilinx Online™ - field upgradability. 


e Problems in creating a stand-alone ASSP. 


The Value of Programmable ASSPs 


ASSPs, designed for a wide array of applications, are 
rarely able to meet your exact needs. With a pro- 
grammable ASSP solution, such as Spartan-I| FPGAs, 
you can choose the optimum feature set and optimize 
your design to achieve best possible results—this 
gives you a better design and saves money. 


The PCI case study shown in Figure 3 is a good 
example. This Spartan-XL PCI solution was able to 
effectively cut the total product cost in half and also 
allow room to accommodate the extra logic that you 
may want to add to the backend PCI interface, such 
as a DMA controller, SDRAM controller, or FIFO. 


Accommodating Specification Changes 


ASSP vendors are motivated to quickly create solu- 
tions for emerging markets because of the high profit 


¢ Spartan FPGAs migrate to higher densities to 
handle system features 


- Maintaining low cost 
¢ ASSPs attempt to offer flexibiity 


- Differentiation need due to 
market pressures 


oe ASSPs require programmable 
ogic 


- Changing system standards 


¢ ASSPs have large role in consumer, 
networking & data-processing 


-Where Spartan FPGAs are successful 
¢ PCI is the first successful ASSP competition 
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Figure 2 - Spartan-ll family penetrates ASSP markets. 


margins they stand to gain. However, the standards 
change constantly in these markets, often making 
ASSPs a risky choice. These conditions create many 
opportunities for the Spartan-Il family, because with a 
Spartan device, you can upgrade your design to 
accommodate evolving specifications even after your 
systems are deployed in the field. 


Testing and Verification 


Another problem users encounter with stand-alone 
ASSPs is that the devices do not always behave as 
expected. Identifying problems is a lot easier with pro- 
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Figure 3 - Xilinx PCI solution vs. stand-alone ASSP. 





grammable ASSPs, such as the Spartan-I| FPGAs, 
because they are built on the fabric of a proven FPGA 
technology and the silicon has been pre-verified and 
guaranteed to perform. Because a programmable 
ASSP is inherently re-programmable, fixing any prob- 
lem is simple. This is a tremendous value-added fea- 
ture that a stand-alone ASSP cannot offer. 


Xilinx Online for Field Upgradability 


The Xilinx Online capability allows you to add new 
hardware features and fix bugs, over a network, with- 
out sending a technician to the field; this can add up 
to considerable maintenance and support savings 
over the entire life of the system. The value of field 
upgradability is illustrated in Figure 4. 


Problems in Creating a Stand-alone ASSP 


Vendors who create stand-alone ASSP devices must 
over-design their products to meet the requirements 
of a wide range of customers. A list of the various 
hurdles that an ASSP vendor faces today are: 
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Figure 4 - Field upgradability extends the value 
of programmable ASSPs. 


Choosing the Right ASSP - The ASSP vendor 
must choose the right market segment. 


¢ Product Customization - ASSP vendors face the 
challenge of creating one solution that must suc- 
cessfully meet the demands of a wide range of cus- 
tomers. 


¢ Development Cost and Amortization - Stand- 
alone ASSPs have high NRE and engineering costs. 
These costs are increasing with process technology 
migration. 


The Spartan-ll family is unaffected by these hur- 
dies and offers a cost-effective programmable ASSP 
solution. 


Spartan-Il ASSP Replacement Value 


The Spartan-Il family replaces and or competes 
against three classes of ASSPs, broadly classified as: 
e Feature-Replacement ASSPs 
e Logic-Replacement ASSPs 

Value-Added ASSPs 


Feature-replacement ASSPs 


Examples of “Feature-replacement ASSPs” are shown 
in Table 1. All of these functions are available ina 
Spartan-II FPGA without using any of the PLD’s logic 
resources. Plus, the price of some of the Spartan-ll 
devices is about the same as that of the ASSP they 
replace. 


Feature Replacement ASSPs 

32-bit SSTL-3 Transceivers with Tristate Outputs 

32-bit to 64-bit HSTL-to-LVTTL Memory Address Latch 
32-bit LVTTL to GTL/GTL+ Transceivers with Live Insertion 
High Speed CMOS Digital PLLs 

















High Speed Programmable Board Skew Clock Buffer 
2K x 8 Dual-Port Static RAM 

64,256,512,1K,2K,4K x 18 Synchronous FIFOs 
Hot Swap Controller 














Note:Pricing shown is approximate and for volumes of 100,000 units 


Table 1 - A list of potential feature replacement 
ASSPs replaced by the Spartan-ll Family. 


Logic-replacement ASSPs 


Logic-replacement ASSPs are those that can be 
replaced by using the logic resources of a Spartan-Il 
chip in combination with various IP cores. Examples 
of potential logic-replacement ASSPs are shown in 
Table 2. 


Value-added ASSPs 


Value-Added ASSPs fall into either of two categories: 


e ASSPs that take unique advantage of the Xilinx 
architecture, like the ATM IMA devices from 
Applied Telecom. The class of field-upgradable 
ASSPs and network processors also fall into this 
category. 

e ASSPs that serve emerging markets and markets 


that do not exist today, such as a PCI-X 
Master/ Target Controller. 


The Spartan-Il family services all three classifica- 
tions of ASSPs very well. Examples of Value Added 
ASSPs are shown in Table 3. 


Conclusion 


The new Spartan-!IIl FPGA family, due to its advanced 
features and low cost, is uniquely capable of replacing 
many standard ASSP devices. And though it may not 





Logic Replacement ASSPs 


Price 





64-bit,66-MHz PCI v2.2 Bus Master 


$ 25.00 





32-bit,33-MHz CompactPCl(r) 
Bus Master Hot Swap Friendly PCI interface chip 


$ 15.00 





32-bit,33-MHz Bus Target chip 


$ 12.00 





32-bit, 33-MHz PC] Master/Slave Controller 


$ 14.00 





32-bit,33-MHz PCI Target Controller 


$ 12.00 





STS-12C/STS-3C POS/ATM SONET Mapper 


$ 120.00 





PCI System Controller for 64-bit MIPS 
CPUs w/ Integrated SDRAM controller 


$ 12.00 





Advanced PCI System Controller for 64-bit MIPS CPUs 


$ 40.00 





Secondary Cache Controller for the R4600/R4700 
Low-Cost 8-Port 10/100 Fast Ethernet Switch Controller 


$ 15.00 
$ 28.00 





High Speed Microcontrollers are direct 
performance upgrades for the 8051 
256-Channel HDLC Controller 


$ 8.00 
$ 60.00 





Multi-Channel HDLC Controller with 32-bit, 
66-MHz PCI Controller 


$ 120.00 





Block Floating Point 16 x 16 Complex 


Floating Point Multiplier 
Programmable FIR Filter 


$ 300.00 
$ 310.00 





Standalone FFT Processor 


$ 450.00 





Integrated Digital Switch 


$ 12.00 





HDLC Protocol Controller 


$ 4.50 





Multi Channel ATM AAL1 SAR 


$ 90.00 





Dual ADPCM Transcoder 


$ 4.00 





Integrated PCM Filter CODEC 


$ 4.00 





Viterbi with Reed-Solomon Decoder 


$ 25.00 





Reed-Solomon Forward Error Correction 


$ 20.00 





ALDC Data Compression 


$ 12.00 





DCLZ Compression 
ISDN Terminal Adapter with HDLC Controller 


$ 22.00 
$ 10.00 





Multichannel Network Interface 
Controller for HDLC 


$ 60.00 





Fast Ethernet (100 Mbps) Media Access 
Controllers (MAC) 


$ 20.00 





Note:Pricing shown is approximate and for volumes of 100,000 units 


Table 2 - A List of potential logic-replacement 
ASSPs supported by the Spartan-ll family. 


Value Added ASSPs 





Price 





64-bit,66-MHz PCI-X System Controller 





Quad ATM IMA Chip 


Octal ATM IMA Chip 


$ 30.00 
$ 50.00 





ARC Processor 





Note:Pricing shown is approximate and for volumes of 100,000 units 


Table 3 - A list of potential value added ASSPs 
supported by the Spartan-ll Family. 





replace all ASSPs, the Spartan family is now being 


used in many new high-volume, low-cost applications 
that were once dominated by stand-alone ASSPs. # 
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A design flow that offers distinct advantages when com 
pared to an ASIC design methodology 





ith the rapid adoptation of deep- 
submicron process technology in 
the design of FPGAs, Xilinx is now 
able to provide you with a cost-effective alterna- 
tive to using an ASIC. But the cost of silicon is 
only one reason why the use of Spartan devices 
in high-volume applications is skyrocketing. 


Spartan devices are designed using our 
robust suite of design tools. These tools have 
become rich in features as a result of the inclu- 
sion of a series of patented innovations. This 
article describes some of the key technologies 
that are included in the Xilinx development sys- 
tems, including HDL optimized flows, timing 
driven layout, core (intellectual property) design 
and integration, and a comprehensive suite of 
verification tools. 


Xilinx design methodology also offers some 
distinct advantages when compared to an ASIC 
design flow. These improvements in the art of 
logic design deliver benefits that reduce the cost 
of design development and accelerate time to 
market. 


by Craig N. Willert, Software Marketing Manager, Xilinx, 
cnw @xilinx.com 
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A Robust Suite of Design Tools 


The development systems that Xilinx delivers 
today incorporate the collective innovations of 
over 15 years of programmable logic design 
expertise. These improvements to the pro- 
grammable logic design process have resulted in 
the creation of a comprehensive, high quality 
suite of design tools. Xilinx development systems 
are packaged to deliver the best value for your 
dollar, enabling you to invest in just what you 
need to get the job done. 


All Xilinx development systems include a 
comprehensive set of key technologies that 
enable the efficient design of powerful, high per- 
formance products. Other tools useful in the 
design of programmable logic are delivered as 
options or as part of the Foundation Series 
“oackaged” solutions, including HDL design, sim- 
ulation, synthesis, and optimization. 


One of the benefits of programmable logic is 
the ability to program (and reprogram) the 
device at your desktop. In order to do so, you 
need a set of tools that take your design from 
concept to silicon. Processing your design 
includes design capture (including HDL synthesis 


and/ or schematic entry), implementation, and 
verification. 


Capturing your Design 


The first step in the creation of any logic design 
is to capture the 
intended functionali- 


ty in electronic for- ALLIANCE 
mat. While Xilinx has 
Ne | a “a 


a rich history in the 
Support of schematic 
capture programs, 
over the last six 
years Xilinx has been 
working with leading vendors in support of HDL 
design flows (synthesis and optimization). This 
investment is paying dividends to designers 
using Xilinx devices in terms of technology spe- 
cific optimizations that enable the creation of 


uae 


a ol 


high performance designs from VHDL or Verilog. 


The Xilinx Foundation Series™ software 
includes synthesis capabilities from industry 
leader Synopsys® (FPGA Express™). To ensure 
the highest quality 
of results through 
the synthesis pro- 
cess, Xilinx works 
cooperatively with 
all synthesis part- 
ners to develop 
proprietary opti- 
mization technolo- 
gy for Xilinx devices. This technology takes 
advantage of the extensive knowledge that the 
Xtlinx R&D staff have of its silicon and imple- 
mentation tools. These improvements are devel - 
oped in a manner which allows them to be 
Shared with third party synthesis vendors to 
ensure high quality results, through HDL design 
flows, regardless of your chosen synthesis 
provider. 
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Xilinx aR 
also delivers 
the industry's lagi * 
best design 
reuse 
methodology, enabling the seamless integration 
of intellectual property from either third parties 
(Alliance cores) or Xilinx (LogiCores). The Xilinx 
CORE Generator™ enables the customization of 
the core’s parameters at your desktop, creating 
the exact functionality that your design requires. 
The use of SmartiIP™ technology in the creation 
of cores ensures predictable, high-performance, 
scalable functions. One of the most popular 
cores is the Xilinx PCI LogiCore, currently offered 
as both 32-bit/ 33-MHz and 64-bit/ 66-MHz 
interfaces. 


Implementation 


Xilinx patented the timing-driven place and 
route of FPGAs in the early 90s. This technology 
allows you to specify timing requirements when 
creating your design, and automatically optimize 
your design with these requirements in mind. 
Advanced integration, between the synthesis 
tools and the Xilinx implementation tools, 
enable the passing of timing requirements from 
synthesis to place and route, and circuit delay 
information from place and route back to the 
synthesis algorithms. 


This closed loop methodology not only saves 
time, by making sure that the place and route 
tools are working to create a design that meets 
all of your system needs, it also provides imme- 
diate feedback when timing requirements are 
unrealistic, given the current design description. 
In fact, the flexible verification methodology that 
Xilinx provides ensures that you are given feed- 
back on the feasibility and quality of your design 
throughout the design flow. This Checkpoint 
Verification™ process ensures that you are 
Spending your time most efficiently. The process 
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Figure 1: Constraints Editor 


continues only with design iterations that will 
converge on your overall system requirements, 
and identifies trouble spots in designs that will 
not. 
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Figure 2: Training Analyzer 


Xilinx has also made great strides in simplify- 
ing the process of timing driven design. The 
Xilinx “Constraints Editor” (Figure 1) guides you 
in your selection of signals and nodes to which 
you will apply timing constraints within your 
design. The Signal and Node lists are based on 
the same names you provided during the cre- 
ation of the schematic or HDL source. 


This easy-to-use GUI provides an intuitive 
interface for using industry’s most comprehen- 
sive timing specification language—TimeSpecs™. 
Once these timing requirements are specified 
and the design is implemented, the Xilinx Timing 
Analyzer (Figure 2) is used to analyze the perfor- 
mance of a design. This intuitive interface 
streamlines the process of evaluating your 
designs timing by enabling a hierarchical analy- 
sis of all of the design’s timing paths through the 
use of (+) expand and (-) collapse functionality. 


The key to many design flows is the ability to 
rapidly iterate between design capture, imple- 
mentation, and simulation (or in-system test). 
Iterative design is one key advantage of using 
programmable logic in your system, and to best 
take advantage of this, fast compilation times 
are important. To this end, Xilinx has dramatical- 
ly reduced the place and route compilation times 
for its Spartan-lIl and Virtex families. Where tra- 
ditional FPGA design flows implement designs at 
approximately 10K gates per minute, Xilinx v2.1i 
tools compile designs at a rate of approximately 
1OOK gates per minute. For Spartan-lIl devices 
this translates into place and route times as fast 
as 1 minute, with average run times less than 10 
minutes. 


Verification 


The increased density and performance of pro- 
grammable logic Is resulting in its frequent use 
as the central component in equipment design. 
As such, the emphasis on verification of pro- 
grammable logic designs is becoming paramount 
to a program’s success. Xilinx Check Point 
Verification methodology provides all of the 
hooks necessary to verify the operation of your 
design within the FPGA and within the target 
system. Elements of the Xilinx checkpoint verifi- 
cation model include: 


Support for functional, gate, and timing simu- 
lation. 


LMG SmartModel™ support for the Xilinx 
FPGA. 


Chip-level static timing analysis. 


STAMP™ model generation for board-level 
static timing analysis. 


In-System debug with Probe™. 


Through this comprehensive suite of verifica- 
tion tools and data files, Xilinx provides you with 
the ability to employ the verification methodolo- 
gy of your choice. Our close relationships with 


our Alliance EDA partners ensure success in the 
use of partner tools, while Xilinx also offers the 
Foundation Series solutions as a complete, ready 
to use package of EDA and place and route 
tools, automating both design compilation and 
verification. 


Improving the Art of Logic Design 


The Xilinx design methodology leverages the 
technological advantages of programmable 
logic, including the fact that all devices shipped 
by Xilinx are 100% functionally verified at the 
factory. This fact alone translates into weeks of 
Savings in design time, as the processes of scan 
insertion and the re-verification of a design after 
scan Insertion is not required. 


Another key benefit in the Xilinx design flow 
is that the device is "fabricated" (programmed) 
by you, at your desktop, or in your manufactur- 
ing organization. Your retention of control of this 
process means that there is no Non-Recurring 
Engineering (NRE) cost associated with the cre- 
ation of the device. This can dramatically reduce 
the emphasis frequently placed on running com- 
prehensive (and time consuming) timing simula- 
tions after layout, and before device "fabricated". 


For programmable logic, a relatively compre- 
hensive verification regimen can consist of func- 
tional verification and static timing analysis if 
good synchronous design practices are followed. 
The streamlined Xilinx design flow reduces the 
necessity of timing simulation, which is fre- 
quently a time consuming process. If your envi- 
ronment calls for the verification of your chip 
design within the board (or system), Xilinx also 
generates the necessary timing information for 
use with board-level static timing analysis or 
Simulation tools. 


The ability to program the Xilinx device at 
your desktop also means that you can quickly 
iterate your design in a "burn and learn“ fashion, 
reducing the pressure to get it right the first time. 
Problems discovered during in-system verifica- 
tion can actually be remedied in the chosen logic 
device. This is particularly useful when industry 
Specifications or marketing requirements haven't 
stabilized prior to the beginning of your project. 


The combination of these factors means that 
the design methodology that you follow is 
streamlined when compared to the process 
required to design with an ASIC. The time saved 
in the design flow and system verification is fre- 
quently dramatic. 


Conclusion 


The advantages of creating your design with 
programmable logic include more efficient use of 
your time, faster time to market, and no NRE 
costs. Our experience has found these benefits 
frequently result in improved market success of 
our customers’ products. In addition to these 
benefits, the development systems required to 
design a Spartan device into your product are 
configured and priced to comfortably fit within 
any budget. Visit The Silicon Expresso Cafe (the 
Xilinx on-line store) or contact your local Xilinx 
sales representative to learn more. $¥ 


See page 63 for an overview of our software products. 
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Spartan-Il FPGAs are used to implement complex 


MP3 system-level glue logic. 


by Jasbinder Bhoot, Manager, Strategic Applications, 
Xilinx, jasbinder.bhoot@xilinx.com 


P3 is rapidly becoming the defacto 
standard for the delivery of high qual- 
ity music on the Internet. This tech- 
nology has been well received as evidenced by 
the over five million MP3 software plug ins that 
have been downloaded to date. This is a testa- 
ment to the future potential of the MP3 technolo- 
gy considering the relatively limited marketing it 
has received to date. 





MP3 ts an abbreviation for MPEG 1 layer 3, 
which is a compressed digital audio format that 
keeps the file size small without losing the quali- 
ty of the original audio. MP3 
allows audio files to be com- 
pressed to approximately 
1/ 11" of the original size. For 
example, a typical music CD 
consumes 650MB; using MP3 
the same audio only takes 
55MB! This has allowed 
music to be stored on the 
PCs hard drive, allowing 
users to effortlessly create 
and customize music play 
lists. 


The compression 
achieved by MP3 makes it 
practical to construct a solid 
state portable audio player 
based upon FLASH memory 
as the storage medium. This 





article explores the development of a portable 
MP3 player using the Spartan-Il FPGA family. 


Design Overview 


The MP3 player discussed in this application 
contains advanced user interface features, such 
as the ability to store contact information, record 
memos, and other functions typically found in 
Personal Digital Assistants (PDAs). The design 
uses an IDT RC32364 RISC processor to decode 
the MP3 data and implement the graphical user 
interface. The Xilinx Spartan-I| FPGA is used to 
implement the complex MP3 
system-level glue logic 
required to interface and 
manage the memory and 
I/O devices. 


Figure 1 shows a block 
diagram of the design. The 
key features are: 


e 128 x 128 pixel graphical 
touch screen. 


e USB interface for music 
downloads and network 
connectivity. 


¢ IRDA-compliant infrared 
interface for exchanging 
data with other units. 


¢ 32 MB of on board FLASH 
storage. 


To Meren The FLASH memory is the Samsung 


eedalioapes 


KM29U64000T 8M x 8 device based on 
NAND FLASH technology. This memory 
iS very popular in MP3 players due to its 
high density and low cost per bit. 
However, this FLASH memory contains 
two characteristics that present signifi- 
cant design challenges: 


a+. * . 
e The KM29U64000T uses a highly 
ocne multiplexed 8-bit-wide port for 


both address and data access. 
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Figure 1: MP3 system block diagram. ° Error detection and correction is 
needed to ensure system integrity. 
e CompactFlash interface for storage expansion 
using CompactFlash cards or MicroDrive hard 
drives. 


The second and most challenging issue, data 
integrity, is common with NAND-based FLASH 
technology. The FLASH memory contains a 
Use of ASSPs range of valid memory blocks (Nvp). For the 
KM 29U64000T the typical Nvp is 1020, the mini- 
mum is 1014, and the maximum ts 1024. While 
the first block is guaranteed to be good, bad 
blocks can occur at any other location within the 
memory array. Invalid blocks are marked at the 
factory by storing a “O” value at location “O” in 
either the first or second block of the page. The 
design must keep a record of good blocks result- 
ing in a non-contiguous memory map. A further 
issue Is that the FLASH memory may experience 


The design uses Application Specific Standard 
Products (ASSPs) to implement much of the 
complex logic. Typically, these ASSPs are not 
designed to communicate with each other. The 
Xilinx Spartan-Il FPGA is used to provide the 
complex glue logic for the interface between the 
ASSPs and the RC32364 RISC processor from 
IDT. 


The Digital-to-Analog converter is the Crystal ~ : | | 
CS4343 from Cirrus Logic. The CS4343 provides adeno! EIeeK failures during the memories 
the analog stereo headphone interface; a serial operational life. 
port is used to transfer digital audio data 


| | Glue Logic Architecture 
streams, while an I*C control port is used to con- 


figure the device features such as volume, mut- Figure 2 shows an overview of the architecture 
ing, equalization, and power management. implemented in the Spartan-II FPGA. 

The USB interface is the USBN9602 from The architecture consists of the following 
National Semiconductor. This device supports functional blocks: 


full soeed USB and includes an integrated USB 
transceiver. The system interface for the 
USBN9602 is an 8-bit microprocessor bus that * CPU interface. 

can be configured to operate in a multiplexed or §° LCD controller. 
non-multiplexed mode. To reduce the number of e Memory Interface. 
pins, the multiplexed mode was used. ¢ SDRAM controller. 


e IP Bus Controller. 


IC 





















CPU Interface 


CHU Address hela 
CPU control 
8 Contra! 
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Sapa 


(—_ 





FLASH Controller. 
CompactFlash Controller. 
IRDA Controller. 

Audio DAC Interface. 
Touch Screen Interface. 


A simple non-multiplexed, multi- master 
address data bus called the IP bus, interconnects 
the blocks. Having the FLASH, SDRAM, and the 
CompactFlash RAM share a common address 
and data bus allows a reduction in pin count. 


The IP Bus has two masters, the CPU inter- 
face and the LCD controller. Multiplexers are 
used for gating data into the internal datapaths, 
eliminating the need for 3-state drivers. 


The CPU Interface performs the CPU ini- 
tialization, the protocol conversion (to and from 
the CPU bus, USB interface, and the IP bus), and 
the address de- multiplexing. 


The LCD Controller is responsible for 
refreshing the screen with the image stored in 
the SDRAM. The LCD controller can obtain the 
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Figure 2: Spartan-ll block diagram. 


data for screen refresh independent of the CPU 
activities. 


The Memory Interface block implements 
the data path required to map the 8- and 16-bit 
memory devices to the 32-bit IP bus. Although 
the RC32364 is capable of obtaining instructions 
and data from devices with varying bus widths, 
using the Spartan-Il to implement this function 
reduces the CPU bus cycles and hence, increases 
performance and reduces power consumption. 


The SDRAM controller is based on the 
design developed by Xilinx in application note 
XAPP134: Virtex Synthesizable High Performance 
SDRAM Controller There are two changes made 
to this design: 


The host interface is adapted from a multi- 
plexed address data bus to a non-multiplexed 
data bus. 


A 16-bit wide SDRAM memory configuration 
iS needed in place of the 32-bit wide memory 
datapath. 


The FLASH Controller copies the exe- 
cutable image from the FLASH memory to the 
SDRAM at boot time, to overcome the FLASH 
random access latency and maximize system 
performance. This method also allows the NAND 
FLASH error code correction to be implemented 
in software, resulting in an efficient use of the 
FLASH memory. 


The CompactFlash Controller provides 
the interface to allow the MP3 music files to be 
stored in to the CompactFlash memory via the 
USB serial link. The control signals required to 
retrieve the MP3 music file for playback are also 
contained in this block. 


The IRDA Controller is essentially a spe- 
cialized, fixed function UART. Separate, 2-word 
receive and transmit FIFOs are used to reduce 
the interrupt overhead associated with data 
transmission. The IR transceiver can support a 
data rate of 115 Kb/s resulting in a CPU interrupt 
every 557 ms. 


The Audio DAC Interface provides the 
dedicated hardware needed to implement the 
transfer protocol for delivering an uninterrupted 
audio stream. This hardware consists of two, 4- 
word FIFOs, one for each audio channel and a 
state machine to manage the FIFOs and 
sequence the interface signals. The audio DAC 
interface also contains a 2-bit I/O port that uses 
software to implement the I*C protocol used for 
accessing the control and status registers in the 
DAC. 


The Touch Screen Interface is an I/O port 
that allows the processor to read the data 
returned by the two-channel analog-to- digital 
converter. This allows the system software to 
determine the X and Y touch screen coordinates. 
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Spartan Device Selection 


Spartan-Il devices are available in a wide range 
of densities and packages. The following criteria 
were used to select the device: 


I/O Pins. The design requires a total of 137 
I/O pins. 


Voltage. The design operates at 3.3V. 


Density. The estimated size of the design is 
83,000 gates. 


Performance. The highest clock speed used in 
this application is 64 MHz; this is used to 
clock the SDRAM controller. The remaining 
logic operates at sub multiples of this clock. 


Packaging. The size constraints imposed on 
most modern designs dictates a high-density 
surface mount package. 


Based on these criteria the device selected 
for this design is the XC2S100. This device offers 
LOOK gate density, 3.3V operation, 176 user I/ Os, 
and is packaged in a FG256 BGA package. The 
cost of this device, in 100K quantities, is $12.95. 


Conclusion 


This design illustrates how Spartan-II FPGAs can 
be used to provide time-to-market advantages in 
high volume consumer applications. In this 
application, the Spartan-IIl FPGA is used as a 
cost-effective device to maximize the CPU per- 
formance and reduce system power consump- 
tion by providing some dedicated functions as 
well as the glue logic required to interface to the 
ASSPs. Using a Spartan-II FPGA also allows field 
upgrade flexibility, in a market where standards 
and protocols are still evolving. # 
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A Programmable ASSP Solution for transmitting high-bandwidth 


data over multiple T1 or El lines. 


by James D. Beatty, President, Applied Telecom, jim@apptel.com, and Krishna 
Rangasayee, Manager, Strategic Applications, Xilinx, krishna@xilinx.com 


he Spartan-Il Family, combined with an 

extensive soft intellectual property (IP) 

portfolio is the first programmable logic 
solution to effectively penetrate the ASSP mar- 
ketplace. The ATM IMA-8 core from Applied 
Telecom, ported to the Spartan XC2S150 device, 
iS a good example, highlighting the concept of a 
programmable ASSP. 


Applied Telecom is the newest member of 
the Xilinx AllianceCORE program and brings a 
wealth of expertise in ATM, SONET, telecommu- 
nications, and networking applications. The 
IMA-8 core, developed, sold, and supported by 
Applied Telecom, targets network access sys- 
tems such as adapters, multiplexers, and switch- 
es. Several leading manufacturers, including 
Alcatel, Ericsson, Nokia, and Nortel, are already 
using Applied Telecom’s Xilinx-based IMA tech- 
nology in production systems. 


What is IMA? 


IMA stands for “Inverse Multiplexing for 
Asynchronous Transfer Mode” (ATM) and it 
allows the transmission of a high-bandwidth 
stream of ATM cells over multiple T1 (1.544 
Mbps) or El (2.048 Mbps) facilities (or circuits). 
IMA is applicable to both public and private net- 
works and allows end users to enjoy the many 
benefits of ATM, such as Quality of Service (QoS) 
provisioning, scalability, and the ability to easily 


mix data, voice, and video. IMA circumvents the 
high cost and unavailability of broadband trans- 
mission facilities such as T3, E3, and 
SONET/SDH by using only as many lower cost, 
lower bandwidth facilities as necessary. With the 
advent of Digital Subscriber Line (DSL) technolo- 
gy, the case for IMA Is even greater. 


IMA Applications 


IMA is applicable to many different types of ATM 
Wide Area Network (WAN) access equipment 
including ATM switches and routers with WAN 
ports, ATM access concentrators and multiplex- 
ers, and communications servers with WAN 
NICs. Typically, IMA is used as the WAN interface 
for general purpose access multiplexers, traffic 
aggregators, and access switches. Another com- 
mon application ts in Digital Subscriber Line 
Access Multiplexers (DSLAMs) where IMA can be 
used either to interconnect the DSLAM with a 
Remote Access Multiplexer (RAM) or as the high 
speed network-side interface. Emerging applica- 
tions are extending the IMA protocol beyond T1 
or El to include other facilities using DSL cir- 
cuits. 


IMA Operation 


Figure 1 illustrates the basic IMA mechanism for 
sending a single ATM cell stream over a number 
of lower speed transmission facilities or links. 
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Figure 1 - Simplified IMA process. 
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Table 1 - IMA sublayer reference model. 
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When splitting an ATM virtual circuit 
among multiple T1 or El links, the IMA 
Subsystem must insert the IMA-specific 
cells into the transmitted ATM cell 
streams. In the receive direction, a cell- 
based IMA framing process is used to 
locate and remove the IMA-specific cells 
so that only the ATM cells are passed to 
the ATM Layer. 


A variable number of physical links 
and ATM bandwidth rates can be sup- 
ported and mechanisms are specified for 
accommodating differential delay varia- 
tions present in the transmission links 
and for handling link failures and 
changes to the available transmission 
bandwidth. 


Layer Reference Model 


In terms of the protocol layer reference 
model, the IMA sublayer is considered to 
be an extension of the Physical Layer 
(PHY), sitting below the ATM Layer (ATM) 
and, as much as possible, transparent to 
the ATM Layer device. Table 1 illustrates 
the functions performed by the IMA sub- 
layer. 


From an ATM layer perspective, the 
behaviors exhibited by IMA groups are 
different than those of real PHY facilities. 
Two examples include the effects of IMA 
group start-up and variations in band- 
width caused by the activation/ deactiva- 
tion and addition/ deletion of links. 


In addition to the PHY layer, IMA also 
affects the management layer. The man- 
agement layer handles alarm detection 
and processing, making it possible to 
configure IMA groups, add and delete 
links, and maintain IMA sublayer statis- 
tics. 


PHY Layer Considerations 


A typical PHY layer implementation with IMA is 
Shown in Figure 2. In many such implementa- 
tions, the Physical Layer function is resident on a 
“line card” which Is physically separate from the 
ATM layer device to allow the ATM device to 
serve many facilities. This co-location of IMA on 
the line card restricts the facilities which can be 
allocated to an IMA group because only the spe- 
cific Tl or El facilities attached to that line card 
can be grouped, limiting the configurability of 
the system. 


One solution, for maximum configurability, is 
to place the IMA function with the ATM layer 
device. But this is usually difficult to implement 
and causes some system-level functional parti- 
tioning problems (such as splitting up the PHY 
layer across modules). A more common solution 
that sacrifices some of the flexibility in assigning 
facilities to IMA groups is to develop the IMA 
functionality and the line card so that each 
T1/ El facility can be independently configured 
to be part of an IMA group or be bypassed 


around the IMA function to be accessed uniquely 
by the ATM layer device. With this solution, the 
line card is no longer a “dedicated” IMA card. 


IMA Solution 


Given the availability of many off-the-shelf 
devices providing the T1/ El line interface, fram- 
ing, and ATM Transmission Convergence (TC) 
sublayer functionality plus the wide acceptance 
and usage of the ATM Forum’s UTOPIA bus 
interface for ATM cell transfer, it is natural to 
define an IMA solution that can be inserted 
between the TC function and ATM layer. With 
the availability of the Spartan-Il family, a com- 
plete IMA solution can be implemented using a 
single XC2S150 device, an external SRAM 
device, and a software driver. 


The IMA-8 Core 


The IMA-8 product is an XC2S150 device 
solution that supports up to eight links and four 
IMA groups. The external interfaces for this 
FPGA device are shown in Figure 3. The IMA 
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Figure 3 - IMA-8 interfaces. 


implementation has 
been partitioned so the 
real-time processes are 


performed in the FPGA = si __fe PHY 
and all non-real time 

processes are performed 

by a software driver. For TolfomTVE1 —BXTRL 


example, all IMA link 
state machines are 
implemented in the 
FPGA but the IMA group 
state machines are 
implemented in soft- 
ware. This partitioning 
eliminates interrupts 
from the FPGA and 
allows the software to 
operate as a periodic 
background task on the processor. 


Framers aid Llc ge @XTRL 
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Functional Description 


A simplified block diagram of the IMA FPGA 
solution is shown in Figure 4. The solution is 
composed of four main functional areas: 


1 - the IMA clock generators. 
2 - the Transmit IMA processing. 
3 - the Receive IMA processing. 


4 - the Microprocessor Bus Interface. 


An IMA software driver completes the IMA 
implementation. To get specific details on these 
components, please contact Applied Telecom or 
the Xilinx High Volume Business Unit. 


Conclusion 


Early deployment of IMA technology meeting the 
IMA v1.0 standard began in late 1997, but due to 
different interpretations of this specification, true 
multi- vendor interoperability was not really pos- 
sible until the completion and acceptance of the 
IMA v1.1 specification in 1999. Throughout this 
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Figure 4 - Functional block diagram. 


period, the changes to the applicable technical 
standard and the lessons learned through inter- 
vendor testing required the flexibility of FPGA 
and software implementations. 


At present, stability in standardization plus 
large scale IMA deployment have set the stage 
for the introduction of standard silicon IMA 
products. But IMA is still an emerging technolo- 
gy with limited test equipment support and com- 
pliance test suites. An FPGA based IMA solution 
with efficient partitioning of hardware and soft- 
ware functions provides the necessary scalability 
and flexibility to handle all of these applications 
and allow for tracking of new standards. 


With the introduction of the Spartan-I| FPGA 
family and the IMA8L core (along with other 
Xilinx-based IMA core solutions) an FPGA based 
IMA implementation is simple and economical. # 


The IMA-8 core is available immediately for use in Spartan-ll FPGAs. An 
evaluation board and the DRV-IMA software are also available now. All 
IMA products can be purchased directly from Applied Telecom.See 
www.apptel.com. 


Controller Solutions 


= Spartan-Il FPGAs 


a 








HDLC Controller cores, ported to the Spartan-II family 
highlight the concept of a programmable ASSP 


DLC Controller cores (soft IP) have 
been available for Xilinx XC4000XL 
and Virtex FPGAs for some time. Now, 
this technology is also available for use with the 
new Spartan-ll family, which is uniquely poised 
to penetrate the ASSP marketplace because of its 
advanced features, high performance, and low 
cost. A programmable HDLC Controller solution, 
with efficient partitioning of hardware and soft- 
ware functions, provides the necessary scalabili- 
ty and flexibility you need for any application, 
and allows you to easily adapt to new standards; 
you get all the benefits of an ASSP device, plus 
the many advantages offered by programmable 
logic. 





HDLC stands for “High-Level Data Link 
Control,” a bit-oriented synchronous data link 
layer protocol developed by the International 
Standards Organization (ISO). HDLC Controllers 
are devices which execute the HDLC protocol 
and their properties include: 


e Transmitting and receiving the serial packet 
data. 


e Providing data transparency through zero 
insertion and deletion. 


e Generating and detecting flags that indicate 
HDLC status. 


e Providing 16-/ 32-bit CRC on data packets 


vy 


by Amit Dhir, Sr. Engineer, Strategic Applications, Xilinx, 
amitd@a@xilinx.com 


using the CCITT defined polynomial. 


Recognizing the single byte address in the 
received frame. 


HDLC Controller Applications 


HDLC Controllers are used In various data net- 
working operations. Some of the key applica- 
tions are: 


Frame relay switches - high density access, 
FRADs. 


ISDN - basic-rate or primary-rate interfaces, 
D-channel. 


X.25 and V.35 protocols. 


Internet/ edge routers, bridges, and switches 
for high bandwidth WAN links. 


Cellular base station switch controllers. 
Error-correction in modems. 


T1/E1, T3/ E3 - channelized, clear channel 
(unchannelized). 


XDSL - each port can support up to 10Mbps. 
Dual HSSI. 
SONET termination. 


Digital sets, PBXs, and private packet net- 
works. 


C-channel controller to Digital Network 
Interface Circuits. 


Data link controllers and protocol generators. 





e |nter-processor communication. 
e Logic consolidation. 

e CSU/ DSU. 

e Protocol converters. 

e Packet data switches. 


e Distributed packet-based communications 
systems. 


e Multiplexer/ Concentrators - remote access, 
multi-service access. 


Xilinx AllianceCORE Partners 


Currently, there are two Xilinx AllianceCORE 
partners supplying HDLC cores for Spartan-I| 
FPGAs: Memec Design Services, and CoreEL 
MicroSystems. 


Memec Design Services (MDS) 


The Single Channel XF-HDLC Controller core 
conforms to the ISO/ IEC 3309 specification, and 
provides the entire functionality of the HDLC 
Controller. The core: 


e Provides 16-/ 32-bit CCITT-CRC a 


generation and checking. 


e Performs flag and zero insertion 
and detection. 


e Allows full duplex operation. 


e Operates at a DC to 53 Mbps 
(STS-1) data rate. 


e Provides full synchronous opera- 
tion. 


e Provides an interface that can be 
customized for user FIFO and DMA 
requirements. 


CoreEL MicroSystems nbs 


Allows 16-/ 32-bit FCS generation and verifi- 
cation. 


Provides an MTU and compression enable 
Signal. 


Provides a scramble and de-scramble enable 
Signal. 


Detects the Address field, Control field, 
escape sequence, and FCS packet errors. 


Provides statistics for Address field, Control 
field, Protocol field, FCS field, and escape 
sequence packet errors. 


Provides statistics such as the number of 
packets, runt packets, valid packets, and 
excess length packets. 


Detects error conditions like Transmission 
Break on transmit side. 


Discards packets received with Address, 
Control, or Protocol field errors. 


Optionally compresses Address, Control, and 
Protocol fields. 


Generates a discard packet signal for any 
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Figure 1 - HDLC Controller block diagram. 
(courtesy: Memec Design Services) 





The PPP8 HDLC core (CC318f) con- 
forms to RFC1619 PPP over SONET 
specification. The core: 


e Supports programmable Address, 
Control and Protocol fields. 


e Supports an 8-bit Packet and PHY 
framer interface. 
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Packets Over SET 


Figure 2 - Application of HDLC cores. 
(courtesy: CoreEL M icroSystems) 


packet with an FCS or invalid packet on pack- 
et interface error. 


A typical HDLC Controller Block Diagram is 
Shown in Figure 1. A typical application is shown 
in Figure 2. 


Comparing the Spartan-Il HDLC Solution 
with Stand-alone ASSPs 


Using an HDLC IP core in conjunction with a 
Spartan-Il FPGA, offers significant advantages 
over a fixed-logic (non-programmable) ASSP. By 
using the Spartan-ll family, you can implement 
the feature sets required and these can be cus- 
tomized to meet the exact design requirements. 


You can also integrate other parts of your 
design within the same FPGA, for increased per- 
formance and reduced cost. For example, an 
HDLC Controller supplied by a stand-alone ASSP 
vendor may include a 32-bit, 33-MHz PCI 
Controller. However, your design may require 
something different, such as a 32-bit, 66-MHz or 
a 64-bit, 33-MHz PCI Controller. By using the 
Spartan-Il FPGA family in conjunction with the 
appropriate cores, you can create the optimal 
HDLC to PCI solution for your specific require- 
ments. Because of the inherent low cost of the 
Spartan-Il family, this flexibility comes at a Sig- 
nificantly lower cost than the fixed ASSP solu- 
tion. Figure 3 shows the value comparison. 


Programmability is Key 


Conflicting specifications and lack of a clear 
direction create the need for programmableASSP 
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Figure 3 - Value comparison. 


solutions. The Spartan-l!l family accommodates 
specification changes and can easily be used in 
volume production. For example, the currently 
available non- programmable HDLC Controller 
solutions are based on X.25 (CCITT) level-2 or 
OSI Layer-2, 1S03309 specifications only. 
However, the solutions provided through 
Spartan-Il FPGAs allow you to use X.25 (CCITT) 
level-2, OSI Layer-2, |S03309, RFC1619 PPP over 
SONET, and ITU recommendation (Q.921) speci- 
fication standards. It would be nearly impossible, 
and cost- prohibitive, for an ASSP vendor to meet 
all of these specifications. 


Xilinx Online for Field Updates 


Through the Xilinx On-line program, the 
Spartan-Il family allows you to remotely update 
your design, over any network. With new fea- 
tures, enhancements, and bug fixes, the life of 
the HDLC controller within any networking sys- 
tem increases. This also allows your equipment 
to adapt to changing standards. Designing sys- 
tems that allow remote upgrades can provide 
new revenue opportunities as well, because you 
can continue to sell new features, after your 
equipment is installed. You cannot easily offer 
these unique features if your hardware design is 
not programmable. 


Conclusion 


The Spartan-Il family is unaffected by the hurdles that 
an ASSP vendor must overcome; its inherent advan- 
tages extend the reach of the Spartan family to new 
levels and creates new opportunities for PLDs in the 
ASSP market. 


The cost difference between a stand-alone ASSP 
and an equivalent programmable Spartan-!I solution 
is considerable. Thus, the Spartan-lIl family is a clear 
winner in not only the HDLC Controller market, but 
also other ASSP niche areas. # 


For more information on the MDS core, see: 
www.xilinx.com/products/logicore/alliance/memec/memec.htm. 
For more information on the CoreEL MicroSystems core, see: 
www.xilinx.com/products/logicore/alliance/coreel/coreel.htm. 
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A look at Spartan-XL power-down modes, small form factor packages, ple 
age power dissipation, and device reliability 


by Ashok Chotai, Senior Competitive Marketing 
Engineer, Xilinx, ashok@xilinx.com 


he Spartan™-XL family is built with an 
advanced 3.3V process, a segmented 
low power architecture, and a power- 
down feature that significantly reduces the 
FPGA’s quiescent current requirements (from 
3mA to 100uA typical). This opens up a whole 
new market for Spartan-XL FPGAs because these 
devices can now be used In power-sensitive 
applications such as laptop computers, cellular 
phones, PDAs, camcorders, and so on. 





Power-down Modes 


There are two kinds of power-down modes: 
manual and automatic. Both provide low quies- 
cent (standby) current while retaining the bit 
map (configuration data with which the device 
had been configured). 


Manual Mode 


In the manual mode, the device is fully inactive, 
the register data is lost, and the activation and 
de-activation are controlled by the PWRDWN 
pin. The following events occur in sequence to 
conserve the power: 


e All inputs (including MO, M1, DONE, CCLK, 
and TDO) except PWRDWN are disconnected 


from their sources. Internal to the device, the 


YC 


input signals are tied to GND. 


All pull-up and pull-down resistors on all I/ Os 
(except PWRDWN) are disabled. 


The Global Set-Reset (GSR) is activated, clear- 
ing all the registers in the device. This reset 
state is held as long as the device is in power- 
down mode. 


The Global 3-state (GTS) is activated, putting 
the device outputs in high-impedance state. 


The device stays in DC state, drawing mini- 
mal power, until PWRDWN goes High, at which 
point it returns to full operation over a period of 
50 ns (max), aS shown in Figure 1. The manual 
power-down mode is described in detail in appli- 
cation note XAPP124 on the Xilinx website at: 
http:// www.xilinx.com/ xapp/ xapp124.pdf. 





Power Down Mode —? 


Description Symbol 





Power-down Time Tpwp 


TPWDW 





Power-down Pulse Width 





Figure 1: Power-down timing. 


Superior Benefits 


Automatic Power-down Mode 


The low power requirements of the 


In the automatic mode the 
device Is active, the register 
data can be retained if required, 
and the power-down is initiated 
without using the PWRDWN 

pin. You can selectively control 
the features of a design, which 
may consume a relatively large 
amount of power, to obtain 
quiescent (standby) current 
down to LOOWUA typical. Some of 
these controllable features are: 


Pull up and pull down resistors on the IO 
pins. 


5V I/O tolerance. 
Clocks that need to run intermittently. 


The redundant use of high-frequency clocks. 


The critical register data can be left operat- 
ing, while disabling the remaining parts of the 
design, to obtain the low quiescent power. 
Unlike the manual power-down mode, this mode 
does not have any power-down recovery time 
when switching back to normal operation. The 
automatic power-down mode ts described in 
detail in the application note XAPP125 on the 
Xilinx website at: http:// www.xilinx.com/ xapp/ 
xapp125.pdf. 


Package Power Dissipation Limit 


Power consumption plays an important role in 
selecting the device package. For the device to 
operate reliably, the power consumed by the 
device must be less than the maximum power its 
package can dissipate. Use the following equa- 
tion to determine the maximum power dissipa- 
tion Pq for a particular package: 


Py = (T) - Th /8) A 


Spartan-XL family makes it possi- 


ages to save board space and 
reduce design costs, making it an 
Cote) meaTo) (occa ce) am naTelsien Ole lace] e)(cmel 10 


low power equipment. 





where Ty is the maximum junc- 
tion temperature, T, is the ambi- 
ent temperature, and 6), is ther- 
mal resistance of the package. 


ble to use small form factor pack- 


Lower power means lower 
heat dissipation requirements, 
thus making it possible to use 
smaller footprint packages. This 
in turn would provide cost sav- 
ings because the package does 
not need to have an extra heat 
sink, and it occupies less board 
Space. As an illustration of this 
power-performance limit, the 
graph shown in Figure 2 plots dynamic power 
with respect to performance for two devices of 
comparable logic density: the Xilinx XCS30XL In 
144-pin Chip Scale package and the Altera 
LOK30A in 144-pin TQFP package. 


Figure 2 shows that the Chip Scale package 
in the Spartan-XL family can be used up to 100 
MHz without any problem with power dissipa- 
tion. However, the TQ package used for the 
Altera 10K30A device cannot be used above 77 
MHz. The device is just not reliable beyond this 
performance. To use it reliably beyond 77 MHz 
performance, you would need to either add a 
heat sink or force air into the package using a 


Dyna mie Cornet (rv 





ferformance (MHz) 


ee Spartan Xl —— FLEX 1030KA eee Power Limit 


Figure 2: Dynamic power comparison of 
Spartan-XL device with 10K30A. 


fan, which means extra hardware, additional 
cost, and more board space. 


Small Form Factor Advantage 


The Chip Scale package (CSP) dramatically 
reduces board space and increases I/ O count; it 
is smaller than any competitive offering in the 
industry. The package is available in 144 and 280 
ball counts with 0.8 mm pitch, and is ideal for 
low-power, light-weight, and small form factor 
designs. Xilinx is the first programmable logic 
Supplier to offer the CSP package 
for an FPGA that meets the JEDEC 
Level 3 moisture sensitivity level 
requirements. This level of reliabil- 
ity enables you to reduce standard 
manufacturing cycle times and fur- 
ther minimize overall system cost. 


1200 


Area (mm) 
: 


As seen in Figure 3, the CS144 | 
package offers 70% board area 1 
Savings when compared with the ae 
TQ144 package. Similarly, the _ 
CS280 package offers 83% board 
area savings when compared with 
the popular PQ240 package. 


Higher Reliability 


Xilinx is Known for quality and reliability. 
Reliability is measured in terms of Failure-In- 
Time rates (FIT); failures in 10° device hours. 
Lower power provides lower FIT rates and high- 
er device reliability, thus reducing product test 
rework and field failures. Overall device reliabil- 
ity decreases exponentially as junction tempera- 
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ture increases. The industry standard limit for 
the maximum junction temperature is 125°C for 
the plastic package and 150°C for the ceramic 
package. Table 1 compares FIT rates of Xilinx to 
that of the nearest competitor. 


Ty (Cc) 50 
Altera 7 








Xilinx fe) 





Table 1 - FIT rate comparison. 
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Figure 3: Package area comparison. 


Conclusion 


The low power requirements of the Spartan-XL 
family makes it possible to use small form factor 
packages to save board space and reduce design 
costs, making it an ideal choice for most 
portable and low power equipment. # 
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CoolRunner devieesire ideal for low- -power, . high- perfor 
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he CoolRunner™ CPLD families are the 
world’s only CPLDs using the patented 
Fast Zero Power (FZP) design technique 
to simultaneously deliver high performance and 
low power consumption. These devices offer 
pin-to-pin (TPD) delays of 5.0 ns (or greater than 
250 MHz system operation), and less than 100 





32 MIC 
be MC 
128 MVC 


UA of standby current (approximately 1/ 3 of the 256 MIC 
power consumed by all other competing CPLDs ini 
at FMAX). Figure 1 - CoolRunner CPLD family 


macrocells. XPLA3 was created to maintain the 
Same competitive advantages as the existing 
CoolRunner families, add additional features, 
and increase performance, while delivering all 
this at a substantially lower cost. 


These characteristics make CoolRunner 
devices ideal for low power applications that 
include portable, handheld, and power-sensitive 
applications. These devices are also idea for sys- 
tems that have a strict power or thermal budget, 
a need for increased system reliability (less 


a XPLA3 Architecture 

power means less activation energy and lower 

FIT rates), a need for lower cost (by eliminating The XPLA3 architecture is based on a PLA 

or reducing the system cooling requirements), or (Programmable Logic Array). The PLA is a pro- 

a need for reduced power supply requirements grammable AND Array combined with a pro- 

(or battery operation). Figure 1 illustrates the grammable OR Array. All other competing CPLDs 

CoolRunner CPLD families. employ a PAL (Programmable Array Logic) that 
combines a programmable AND Array with a 

The XPLA3 Family fixed OR Array. Having a programmable OR 
Array allows product terms (PTs) to be shared 

The XPLA3™ (eXtended Programmable Logic between macrocells (effectively increasing 

Array) is the newest CoolRunner CPLD family, design density because there is no duplication of 

and includes devices ranging from 32 to 384 logic), excellent pin locking (every PT is available 
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to every macrocell), and very simple timing 
model (timing remains the same regardless of 
how many PTs are used). 


The XPLA3 architecture includes a pool of 48 
product terms that can be allocated to any out- 
put in the logic block, a direct input register 
path, multiple clocks (both dedicated and prod- 
uct term generated), and both reset and preset 
for each macrocell. 


Figure 2 illustrates the logic block architec- 
ture. Each logic block contains control terms, 
clock terms, PLA array, and 16 macrocells. There 
are 36 pairs of True and Complement inputs 
from the ZIA that feed the programmable OR 
array. In addition there are 8 foldback PTs that 
are available for ease of fitting and pin retention. 
Also within the 48 p-terms there are eight local 
control terms (LCT 0-7) available as control 
inputs to each macrocell for use as asyn- 
chronous clocks, resets, presets, and output 
enables. The other PTs serve as additional single 
inputs into each macrocell. Sixteen of these are 
coupled with the associated programmable OR 
gate into the VFM (Variable Function 
Multiplexer). The VFM increases logic 
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Figure 2 - XPLA3 Logic Block architecture. 


optimization by implementing any of the OR, 
XOR, XNOR, or NOR functions before entering 
the macrocell. 


Each macrocell can support combinatorial or 
registered inputs; a global preset and reset for 
each macrocell; and configurable D, T, or L regis- 
ters, with maximum clocking flexibility. Each of 
these flip-flops can be clocked from any one of 
nine sources. There are two global synchronous 
clocks that are derived from the four external 
clock pins via a four-to-two multiplexer. There is 
also one universal clock signal sourced by a 
global control term. The clock input signals 
LCT4-LCT7 (Local Control Terms) can be individ- 
ually configured as either a product term or sum 
term equation created from the 36 signals avail- 
able inside the logic block. 


Conclusion 


The XPLA3 CoolRunner CPLD family simultane- 
ously delivers both high performance and low 
power consumption at a very competitive price, 
and will be the lead CoolRunner CPLD family for 
Xilinx in 2000. # 
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Power Estimator Too! 


Here’s how to determine how much power your design will use. 


by John Hubbard, CPLD Applications Engineer, Xilinx, 
john. hubbard@xilinx.com 


he CoolRunner Power Estimator tool 
was developed to help you estimate the 
power consumed by your CoolRunner 
CPLD designs. This is an easy to use spreadsheet 
and Perl script available for download from the 
Xilinx website. The latest version is available for 
download from WebPACK™ by selecting the 
Utilities button. 





Estimating Low Power 


Estimating the power consumption of 
CoolRunner CPLDs is quick and easy. After you 
have targeted a particular device, you import the 
data created by the Perl script into the spread- 


Sheet. Then you enter only two types of parame- 
ters: 


e Signal frequencies for all signals. 
¢ Output loading capacitance. 


Output capacitive loading can be specified 
for each individual pin or specified as a default 
value for all pins. 


Displayed in the spreadsheet (Figure 1) are 
three end results based on these two input 
parameters: 


¢ Total lgg consumed by the design. 
e Total power consumed by the design. 


e Total power consumed by output capacitance 
loading. 


Geral Infarnraion 





Figure 1 - Device data sheet showing results. 
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Figure 2 - Logic Block A sheet showing signal details. 


There are estimates throughout the tool that 
show I qq for specific architectural areas in the 
device as shown in Figure 2. For example, if you 
are attempting to reduce the overall device cur- 
rent, you can see what fast module or logic 
block is consuming the most current. Then it is 
easy to see what specific signals are demanding 
the most current within a logic block, because 
the current estimations for individual signals are 
shown. 


In addition to the power esti- 
mation, this tool can assist you 
during the fitting process by dis- 
playing other important informa- 
tion. For example, statistical data 
for each individual signal is 
available including pin number, 
fan-in number of product terms, 
and fan-out number of product 
terms that load the signal. Fan-in 
data from the Zero Power 
Interconnect Array (ZIA) can eas- 
ily be seen for each logic block 
as well as the fast module Global 
ZIA fan-in and fan-out data for 
XPLA2 devices. 


This extra data is quite useful 
in determining the layout of a 
design within the CoolRunner 
device; you can effortlessly see 
the details of how the fitter 
arranged the design. Using this 
information, your design can be 
rearranged to better improve the 
timing performance. 


Conclusion 


The CoolRunner Power Estimator 
tool is an easy way to estimate 
power and | qq information. Not 
only can you determine the power loading, you 
can also use this tool to help improve timing 
performance by visually interpreting the results 
in the spreadsheet. #: 
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12?C Bus Controller ins 


CoolRunner CPLD 


Here’s an overview of a complete design that you can download from the Web. 


by Jennifer Jenkins, Applications Engineer, Xilinx, 
jennifer.jenkins@xilinx.com 


he IC bus is a popular serial, two- 
wire interface used in many sys- 
tems because of its low electrical 
overhead. The two-wire interface mini- 
mizes interconnections so ICs have fewer 
pins and the number of traces required on 
printed circuit boards is reduced. The bus 
iS Capable of up to 100KHz operation, and 
each device connected to the bus is soft- 
ware addressable by a unique address with 
a simple master/ slave protocol. 





Designing with an |°C bus for handheld 
devices requires that you minimize power 
dissipation. That’s why CoolRunner CPLDs, 
the lowest power CPLDs available, are the per- 
fect devices for creating I*C controllers. The I*C 
design shown in this article provides both mas- 
ter/ slave capability with an asynchronous byte- 
wide microcontroller or microprocessor inter- 
face as shown in Figure 1. 


Functionality 


The CoolRunner CPLD implementation of the I*C 
controller supports the following features: 


e Microcontroller interface. 
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Figure 1 - CoolRunner FC Bus Controller. 


Master or Slave operation. 
Multi-master operation. 
Software selectable acknowledge bit. 


Arbitration of lost interrupts with automatic 
mode switching from Master to Slave 


Calling address identification interrupt with 
automatic mode switching from Master to 
Slave. 


START and STOP signal generation/ detection. 
Repeated START signal generation. 


Acknowledge bit generation/ detection. 
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Figure 2 - CoolRunner PC Controller block diagram. 


Bus busy detection. 


LOOKHz operation. 


Block Diagram 


The functionality of the CoolRunner I?C controller 
IS divided into two major blocks, the microcon- 
troller interface and the I°C interface, as shown 

in Figure 2. This design was created in VHDL 
and verified through simulation. Xilinx software 
tools were used for compilation and fitting. The 
design was targeted to a 3V, 128-macrocell, 
enhanced clocking, CoolRunner CPLD in a 100- 
pin TQFP package (XCR3128A-10VQ100C). 


Conclusion 


This design offers a way to use an I’C bus ina 
low power application. Using a CoolRunner 


CPLD to implement the functionality of an I*C 
controller is perfect for power limited applica- 
tions. The design of the I*C controller that is cur- 
rently available for customers includes the fol- 
lowing: 


Complete detailed application note 


Complete VHDL source code 
VHDL test benches # 


More information can be found at www.xilinx.com/apps/epld.htm,under 
CoolRunner XAPP315 - Implementing an I?C Bus Controller in a 
CoolRunner™ CPLD. The VHDL code and test benches created for 
this design are available by contacting 
Xilinx Technical Support at 1-800-255-7778. 


How to Create an 


Portable Player Using a 





CoolRunner 


CoolRunner CPLDs are used as the main controller for 
an MP3 player. This design is available for download 


from the Web. 


by Anita Schreiber, CPLD Applications Engineer 
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ortable MP3 players are the latest trend 

in music-listening technology; they 

require no moving parts, and can be 
built with very few components. And, because 
these devices are battery operated, they require 
low power technologies. That’s why the new 
CoolRunner CPLD family from Xilinx is ideal for 
this application; this family offers advanced 3V 
and 5V devices with extremely low power dissi- 
pation. 


Block Diagram 


The block diagram of the CoolRunner MP3 
Portable Player is shown in Figure 1. The shaded 
area shows the logic that is contained in the 
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CoolRunner CPLD. All other blocks are external 
devices that can be obtained commercially. 


CoolRunner CPLD Logic Modules 


The CoolRunner CPLD implements the following 
functions: 


e The Main Control Logic provides the intelli- 
gence of the CPLD logic and controls all of 
the various functions. 


e The Parallel Port Interface is used to 
downloading MP3 data files to the MP3 
portable player. 


e The Flash Control logic directs the Song 
Flash memory during MP3 data storage and 
retrieval. It also controls the Starting Address 

Flash memory which stores the begin- 
ning address of each song in the Song 
Flash memory. 


he ache ee el 


e The I°C Master logic block controls 
the DAC3550A Digital-to-Analog 


2 converter. 

tote e The User Interface Control logic 
: na receives the user input and updates 
: the LCD display. 


e The Power Management logic 
monitors the power level reported 


Figure 1 - MP3 portable player block diagram. 


DA 


User Interface Button Function 





Play Pressing this button allows the user to continuously play MP3 songs. 


When the last song has been played,the MP3 player begins playing the first song again. 


Rewind 


Pressing this button allows the user to skip to the beginning of the previous song. 





Fast Forward 


Pressing this button allows the user to skip to the beginning of the next song. 





Stop Pressing this button will halt playing of MP3 songs and resets the player to the beginning of the current song. 





Volume/M ute 


from the internal DC/ DC converter in the 
MAS3507D and insures the MP3 Portable 
Player shuts down properly when the battery 
voltage drops or the user wishes to turn the 
player off. 


External Devices 


The MAS3507D MP3 Decoder chip and the 
DAC3550A Stereo Audio DAC are both available 
from Micronas Intermetall and provide a com- 
plementary chip set for MPEG decoding and 
playback. The MAS3507D contains an embedded 
DC/ DC converter which is used to supply the 
power to the entire player. 


The Flash memory bank is composed of 
32Mbytes of Flash memory for the storage of 
MP3 data files and 2Mbytes of Flash memory for 
the storage of the starting addresses of each 
song in the Song Flash memory. This design 
assumes that an LCD display could be designed 
with unique icons for the various MP3 user inter- 
face functions. 


The volume can be increased and decreased as desired. The player can also be muted. 





Table 1 - User interface functions. 


User Interface Functions and Operations 


The design of this MP3 portable player assumes 
that a software package is designed that allows 
users to “rip” CDs and download a collection of 
their favorite MP3 files to this portable player. 
The user operations for listening to MP3 songs 
are shown in Table 1. 


Conclusion 


CoolRunner CPLDs provide the ideal pro- 
grammable logic solution for any battery-operat- 
ed or portable design. This design shows just 
one example of how a CoolRunner CPLD can be 
used in these types of applications to provide 
you with the many benefits of programmable 
logic while meeting the stringent power require- 
ments of this market. ¥ 


For more information,the following can be obtained from the 
Xilinx@ Work section of the Xilinx website 
(http://xilinx.com/products/xaw/index.htm): 


¢ Detailed Application Note (XAPP328) 
¢ VHDL Source Code 
¢ VHDL Testbenches 
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 Virtex-E FPGAS 


irtex-E FPGAs contain a number of 

architectural features that enhance I/ O 

timing. Four dedicated clock buffer net- 
works allow low skew distribution of clocks to a 
large number of loads, while guaranteeing zero 
hold time requirements between registers. You 
can also use on-chip clock Delay Lock Loops 
(DLLs) to effectively eliminate the phase differ- 
ence between a clock external to the FPGA and 
the internally buffered equivalent. Plus, each 
Virtex-E I/O block (lIOB) contains both an input 
an output register, which can be used to improve 
I/O timing. 


The setup time for a signal brought on chip is 
the sum of the I/ O pad delay, any routing and 
logic delays, and the intrinsic setup time of the 
register or latch, minus any clock delay. Clock 
delay is the sum of I/ O pad delay, any clock 
buffer delay, plus routing and loading delays. Of 
these items, only the I/O pad delays and register 
setup times are known precisely. All other fac- 
tors are design dependent. Clock-to-out times 
require similar calculations, except that any 
clock delay worsens the clock-to-out time. 


by Randy Robinson, Xilinx, randy.robinson@xilinx.com 
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You can achieve I/O setup times of less than 1.6 ns, and I/O clock-to-out times 
of less than 3.3 ns, using LVTTL switching levels. 


Registering Input Signals 


Based on your system timing requirements you 
can allocate a setup time, hold time, and clock- 
to-out timing budget for the Virtex-E device. 
Typically, you are looking for the minimum 
required setup time for the FPGA, and zero (or 
negative) hold time. 


The system-level timing specification refer- 
ences all input signal and clock timing values to 
the pins of the FPGA device. For example, a 5ns 
setup time budget means: 


e Valid data will exist at the FPGA pin a mini- 
mum of 5ns prior to an active clock edge at 


the pin of the FPGA. 


The timing at the FPGA register used to cap- 
ture this input signal must meet its own setup 
and hold time requirements. 


It is mandatory that both of these require- 
ments be met within the overall system timing 
budget. 


You can alter input timing when using Virtex- 
E chips by controlling the following choices: 


Selection of IOB and CLB 


In Virtex-E FPGAS, input signal registers can be 
located in either lIOBs or in CLBs. An advantage 
of using an IOB register is that the data path 
delay (consisting of I/O pad and buffer delays, 
plus routing) is fixed. If a CLB register is used, 
the routing delay will vary depending upon 
where the CLB Is placed, and the routing path 
taken. 


Using the appropriate timespecs can improve 
the setup timing when using CLB registers, but 
will not cause the Alliance Series™ or 
Foundation Series 2.11 software to move regis- 
tered signals between IOB or CLB registers. If the 
source netlist contains register components with 
the property IOB =TRUE, these will not be 
moved. However, by either setting a MAP com- 
mand line switch (map -pr i) or through enabling 
a GUI-based option to allow MAP to pack regis- 
ters into the IOB cells, then a netlist which did 
not contain |IOB registers can use IOB registers if 
possible. 


Using DLLs 


If a clock is distributed using a global buffer only 
(not a clock DLL) there is a delay between the 
clock at the FPGA input pin and the clock inter- 
nal to the FPGA. This delay is beneficial in that it 
reduces the required setup time for the input sig- 
nal. If a clock DLL is used, the propagation delay 
is effectively zero, and the equivalent system 
setup time Is increased. This apparent disadvan- 
tage of using a clock DLL is offset by removal of 
the delay element (described in the next para- 
graph), and the improvement in clock-to-out 
times. 


Using or Eliminating the 1IOB Delay Element 


By default, a delay element is placed in the data 
path of the IOB. This delay block is used to guar- 
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antee a zero hold time for the IOB register, but 
has the effect of increasing the required setup 
time. If a clock DLL output is not used as the I/ O 
register clock, and the delay element is removed, 
the setup time required will decrease dramatical- 
ly, but now a positive hold time exists. 


If you use a clock DLL, the delay element can 
safely be removed, giving you the dual benefit of 
less required setup time and a negative hold 
time. Beginning with the Alliance Series and 
Foundation Series 2.11 Service Pack Number 2, 
the delay element is included only when a DLL Is 
not used and an IOB input register is used. This 
default behavior was changed from earlier soft- 
ware versions. 


Registering Output Signals 


When you are driving a registered signal off chip, 
you must meet a system clock-to-output specifi- 
cation. Fortunately, you have a number of simple 
options that can be used to meet this timing 
when using Virtex-E devices. The choices 
include: 


Using IOB or CLB registers 


You can choose whether the output register is an 
IOB register or a CLB register. The l|OB register 
will always have a shorter routing path from reg- 
ister output to FPGA pin, so the fastest clock-to- 
out time will always be achieved by using the 
IOB register. Timespecs alone will not force the 
Alliance Series or Foundation Series 2.1i soft- 
ware to make the register type decision. 
However, by either setting a MAP command line 
switch (map -pr o) or through enabling a GUI 
based option to allow MAP to pack registers into 
the IOB cells, OB output registers will be used, if 
possible. 


Run #1 
Baseline 


Run #2 
Timespecs 


Run #3 
Add Pack |OB 
Registers 


0.906 ns 0.442 ns 1.795 ns 


8.934 ns 9.082 ns 6.554 ns 


2.407 ns 2.214 ns 5555 


7.837 ns 7.924 ns 5.o25 mS 


Run #4 
Add NODELAY 


6.554 ns 
1.555 ns 


or Ou 





-0.403 ns 


Run #5 
Add Fast Slew 


Run #6 
Add24 ma Drive 


Run #/ 
Pick Best Results 


-0.403 ns -0.403 ns 1.795 ns 


4.654 ns 4.453 ns 4.453 ns 


1555 1s Spo s P555 ms 


3.425 ns 3,224 ns 3,224 ns 


* The gray shading indicates a positive hold time requirement. 


Using Clock DLLs 


Any delay of the input clock due to clock buffer 
and clock routing delays adversely effect clock- 
to-out timing, because this delay simply adds to 
the overall datapath delay. The use of a clock 
DLL will always result in faster clock-to-out 
times in a Virtex-E FPGA. 


Using Slew Rate and Drive Strength Options for 
LVTTL Outputs 


If LVTTL output buffers are selected, you can 
choose between seven drive strengths, and 
between fast and slow slew rate. By default, a 
Virtex-E output buffer defaults to LVTTL, 12ma 
drive, and slow slew rate. To improve clock-to- 
out times, select a higher drive strength (l6ma 
or 24ma) and fast slew rate. The place and route 
software will not modify output buffer settings to 
meet a timespec; you must do this explicitly, typ- 
ically by using a constraint file. 


Summary of Recommendations 


Use IOB input and output registers when pos- 
Sible. 


Use clock DLLs when possible. 


Set fast slew rate and 24ma drive for LVTTL 
|/O to get fastest clock-to-out times. 


Table 1 - Runtime results. 


Set NODELAY mode when using clock DLLs 
to get shortest setup time. 


If clock DLLs are not used, NODELAY will 
greatly shorten your setup time, at the cost of 
a positive hold time. 


Xilinx created a simple design to demon- 
strate the effects discussed above. The results 
are shown below. 


Test Results 


In Table 1 Run #1 shows the registered I/ O tim- 
ings using default settings and CLB registers. By 
adding timespecs (5ns setup, 10ns clock-to-out), 
results changed slightly (Run #2). Packing regis- 
ters into l[OBs (Run #3) gives a better clock-to- 
out delay, and a slightly worse setup time. The 
timing effects of setting NODELAY (Run #4), plus 
fast slew rate (Run #5), plus high drive (Run #6) 
are shown. Finally Run #7 gives the best results 
with zero hold time in all cases. 


Conclusion 


With new Virtex-E family you can easily achieve 
very fast registered I/O timing. # 


For complete information on Virtex-E FPGAs, see www.xilinx.com. 


Understanding 


Setup and Hold Times 
oneK @Y Co Successful Designs 


Using synchronous design techniques is one essential 
key to creating reliable designs. 
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he Xilinx software technology J Tp); Th can safely be ignored with 
provides all the information you | --~-- Xilinx FPGAs (Tp is 0). See Figure 1. 
need to create reliable, high | = 
performance designs, but you should 
make sure that you don’t violate two of 
the most important parameters: 
setup and hold time. 











If the setup and hold times are 
not violated, the data on the D input 
is transferred to the Q output, 
after the flip-flop clock-to-out- 

put delay (T cho). However, if 

Toy or Tp timing is not 

met, the Q output Is inde- 
terminate. 


The Basics 


Synchronous elements such 

as D flip-flops (DFF’s) accept 
the data present on their D 
inputs when the clock transi- 
tions. However, the data must 
be stable prior to the clock edge 
(setup time, T<y) and maintained 
after the same clock edge (hold time, 


Controlling Logic Paths 


A real design is usually 
made of thousands of flip- 
flops, with several levels of 
logic between them, and moder- 
ate to high utilization of routing 





Figure 1 - Setup and hold timing. 
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resources. All those paths, from a data source 
element (PAD, FF, RAM...) to a receiving element 
(PAD, FF, RAM...), are Known as logic paths. 


Controlling those paths (giving the imple- 
mentation tools the adequate directives to meet 
the timing criteria) is one key to success. In the 
Xilinx software tools, there are several graphical 
tools (Constraints Editor, FloorPlanner) to help 
you pass the right control information to the 
Implementation Engine. Another set of verifica- 
tion tools (the GUI or command-line-driven 
Timing Analyzer or TRCE) give you everything 
you need to check your results. But, what If 
some of your timing criteria are not met? Is your 
design failing because the timing constraint is 
not possible to meet ? If so why? Is it failing 
because of a setup time violation or a hold time 
violation? And, how do you fix the problem? 


If your timing is OK, you'll get a Timing 
Analyzer message (in the .TWR report) that says 
“All Timing Constraints met.” If your timing Is 
not OK, you'll see messages that tell you why 
(such as “...clock frequency too high,” or “...too 
many logic levels for the requested frequency,” 
or “ ...too much routing delays versus logic 
delays,”) and you will be given the actual timing 
difference. 


Two Examples of Clock Distribution 


Consider a logic path starting at the Q output of 
a flip-flop, going through a number of logic 
stages, and ending at the D input of a another 
flip-flop, as shown in Figure 2. The safe opera- 
tion is specified by the equation: 


Tok 2 Tekg + (logic and routing delays) + Toy, 
The Best Case - Minimal Clock Skew 


In an ideal design, there will be minimal clock 
Skew (all flip-flops see the clock edge at the 






Din 





Figure 2 - Basic timing model. 


Same time, within a few hundred picoseconds). 
For synchronous designs, the optimum clock dis- 
tribution is obtained when you use one of the 
dedicated clock routing resources attached to a 
global buffer (BUFG). Depending upon the FPGA 
you select, you have from two to eight BUFGs 
available. 


For a given clock frequency, and for a given 
FPGA, you only have to control the number of 
logical levels (logic delays) the signal passes 
through, and make sure that this sum of delays 
does not exceed the clock period. 


How to Correct the Problem 


Figure 3 shows an excerpt of a report, showing a 
timing error. The report shows that we missed 
our timing goal (the slack value is negative, - 
0.662ns). We have a 67% logic budget for a 33% 
route budget (Xilinx recommends the opposite. A 
50/ 50 ratio is generally OK for small design, and 
the bigger the chip, the bigger the recommended 
route budget (40/ 60 or 30/ 70). 


The best solution is to decrease the number 
of logic levels; this will remove one combinatori- 
al logic delay (Tjj>) and one net delay. An alter- 
native would be to simply use a faster speed 
grade, because the you only need to gain 0.66ns. 
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Timing constraint:TS_ CLK = PERIOD TIMEGRP “CLK”5 nS HIGH 50.000 % ; 
1 item analyzed,1 timing error detected. 
Minimum period is 5.662ns. 


Slack:-0.662ns path DLY1 to $Net00012_ relative to 
5.000ns delay constraint 


Path DLY1 to $Net00012_ contains 4 levels of logic: 

Path starting from Comp:CLB_R5C4.K (from $Net00004_) 
To Delay type Delay(ns) Physical Resource 

Logical Resource(s) 


CLB_R5C4.XQ Tcko 1.192R DLY1 
$13/$1137 

CLB_R5C4.F1 net (fanout=1) 0.530R DIN Q 
CLB_R5C4.X Tilo 0.959R DLY1 

$18 

CLB_R5C5.F1 net (fanout=1) 0.832R DLY1 
CLB_R5C5.X Tilo 0.959R DLY2 

$19 

CLB_R6C5.F1 net (fanout=1) 0.522R DLY2 
CLB_R6C5.K Tick 0.668R $Net00012_ 
$110 

$17/$1137 


Total (3.778ns logic,1.884ns route) 5.662ns (to $Net00004 _) 
(66.7% logic,33.3% route) 





Figure 3 - A .TWR report showing a timing violation. 


The Worst Case - Significant Clock Skew 


In designs where the number of clocks exceeds 
the dedicated BUFG clock resources, some of the 
clocks will need to use the non-dedicated, stan- 
dard, routing resources which will introduce 
clock skew. It’s best to assign the fastest, high 
fanout, clocks to the dedicated BUFG routing 
resources. How does clock skew affect the 
design? And, how do you minimize its negative 
effects? 


In Figure 4, the FFB clock is delayed from the 


FFA clock (skewed) and there Is a direct connec- 
tion from the Q output of FFA to the D input of 
FFB. 





de 





Figure 4 - Synchronous circuit with clock skew. 


For FFB to clock in the correct data, you must 
respect the following condition : 


Toko (FFA) > SKEW 


However, due to the clock delay, the D out- 
put of FFA may be unstable, changing, when FFB 
receives the clock edge, causing FFB to latch the 
wrong data. The CLK frequency does not affect 
the problem, therefore reducing the CLK speed 
won't solve the problem. 


Once again, the .TWR report will give you the 
detailed information you need to identify and 
correct the problem. In the report, shown in 
Figure 5, you can quickly see that you missed 
your timing goal (the report shows negative 
Slack, -3.234ns). The summary gives a (logic + 
route delay) of 3.06ns for a 6.6ns clock skew; 
The message “6.592ns skew between D_186 and 
D_188” should alert you to a probable data hold 
violation. 


Slack: -3.234ns path D_186 to D_188 relative to 
6.592ns skew between D_186 and D_188 


Path D_186 to D_188 contains 2 levels of logic: 
Path starting from Comp: CLB_R45C25.S0.CLK (from clk_0) 
To Delay type Delay(ns) Physical Resource 


Logical Resource(s) 


CLB_R45C25.S0.YQ Tcko 1.065F D_186 
genck_0 genreg 185_ ff 


CLB R45C10.S0.BY net (fanout=1) 2.127F D_186 
CLB_R45C10.S0.CLK Tckdi -0.166F D_188 
genck_0 genreg 186_ ff 


Total (0.899ns logic, 2.127ns route) 3.026ns (to clk_0) 
(29.7% logic, 70.3% route) 





Figure 5 - Timing report showing clock skew. 


How to Correct the Problem 


The easiest solution is to compensate for the 
clock skew by adding dummy logic in the data 
path to delay the data. 


Another solution ts to propagate clock and 
data in the opposite direction, as shown in 
Figure 6, (this may require manual edits, using 
the FPGA_Editor). You'll still get skew, and it will 
be reported in the .TWR, but you won't experi- 
ence data Ioss. 


Compared to the first equation, now you 
have the following relationship: 


Tek-Skew = Tek + (logic and routing delays) + Toy 


This simply means that you now have less 
time for logic and routing delays, and you'll have 
to be careful not to violate the receiving flip-flop 
setup time, especially for high frequency opera- 
tion. 


Of course, the best solution would be to use 
BUFG to distribute the clock, which will elimi- 
nate the skew entirely. 


dizia propa gala 
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Figure 6 - Controlling the effects of clock skew through 
propagating the clock in the opposite direction. 


Conclusion 


The techniques discussed here apply to any type 
of logic design, not just programmable logic. 
However, it’s easy to get reliable results with 
Xilinx components because they include special 
clock distribution networks (BUFGs). In our 
newer families (Virtex, Virtex-E, SPARTAN-II) we 
also include Delay Locked Loops that eliminate 
skew for both on-chip and off-chip clocks. # 


If you need more help, go to www.support.xilinx.com 
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Inferring Virtex SRL macros results in extremely efficient Linear 
Feedback Shift Register implementations. 


by Mike Gulotta, Field Application Engineer, Xilinx, 
mike.gulotta@xilinx.com 


inear Feedback Shift Registers (LFSRs) 

are a fundamental function in applica- 

tions such as pseudo-random noise (PN) 
generators, stream encryption, and error detec- 
tion/ correction. You can achieve extremely effi- 
cient LFSR implementations by using the Virtex 
Shift Register LUT (SRL). And, with today’s 
Virtex-friendly synthesis tools, HDL code can be 
used to infer the SRL, thereby maintaining code 
portability. 


PN Generators 


PN generators are at the heart of every spread 
spectrum system, and are a good example for 
demonstrating how you can dramatically reduce 
FPGA utilization by exploiting the Virtex SRL. In 
a CDMA system, many PN generators are needed 
to distinguish channels, base stations, and hand- 
sets. Rake receivers, used in CDMA systems, 
consist of many copies of the same receiver, 
each called a finger, and each finger requires 
two PN generators, one for the “I” (In-phase) and 
one for the “Q” (Quadrature) channel. 


Finding a way to improve the FPGA imple- 
mentation efficiency of a circuit that is copied 


AD 


many times in a system (Such as a PN genera- 
tor), will obviously provide a huge savings. 


Linear Feedback Shift Registers 


Though the mathematics behind a PN code can 
be extremely complicated, the LFSR implementa- 
tion can be relatively simple. A typical LFSR con- 
sists of a chain of registers and a modulo-2 
adder (XOR gate). Predefined registers are 
“tapped” and fed to the XOR gate, and the XOR 
output is fed back to the first register in the 
chain, as shown in Figure 1. In a CDMA system, 
the predefined register taps are carefully deter- 
mined to provided good auto correlation and 
cross correlation, and are often expressed as a 
polynomial such as, P(x) =xl/+x4+41.AnLFSR 
with n registers can sequence through (2" - 1) 
states. (See Xilinx XAPP 210 and XAPP 211 for 
additional information regarding LFSRs and 
SRLs). 





a 
Figure 1 - A typical LFSR. 


CDMA system requirements may require 
additional control of the basic LFSR. 
“Augmenting” the sequence, by adding an addi- 
tional state, may be required to achieve 2° states 
(instead of 2" - 1), to maintain an even modulo 
count. Also, “puncturing” the sequence by perli- 
odically skipping a state may be required, if only 
a subset of the total 2" states (Such as 3 out of 4) 
are needed. 


LFSR HDL Coding 


The Virtex FPGA architecture is highly efficient 
for creating LFSRs. For example, the following 
code will infer a 64-bit shift register using Virtex 
SRLs rather than flip-flops (FFs). 


VHDL Verilog 


process(clk) Always @(posedge clk) begin 
begin Y <= {¥[62:0],INPUT} 
if clk’event and clk='1’ then end 
Y <= Y(62 downto 0) & INPUT; 


end if: 


end process; 


Figure 2 - HDL Code. 


Using SRLs instead of FFs, this circuit will 
cost only one Configurable Logic Block (CLB) 
instead of 16. With such dramatic savings it is 
worth looking into ways to use SRLS whenever 
possible. 


However, SRL registers cannot be loaded or 
read simultaneously, nor can they be asyn- 
chronously reset. In a PN generator application it 
may be necessary to jump out of sequence, 
which can be done by various techniques such 
as parallel loading the LFSR with a predeter- 
mined state. This can still be satisfied with the 
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SRL by serially filling the LFSR with a predeter- 
mined state. To do this, a multiplexer is required 
in the LFSR feedback path allowing the loop to 
be broken while the predetermined state is shift- 
ed in, as shown in figure 3. 
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Figure 3 - PN generator. 


The following verilog code implements an 
LFSR with several input controls that may be 
used to accommodate a PN generator applica- 
tion. The ShiftEn signal may be used to stall 
(augment) and/ or puncture the sequence, and 
the FillSel and Dataln signals may be used to 
jump out of sequence. The define compiler 
directive along with the Reset signal provide 
code portability by allowing the code to infer 
SRLs if targeting Virtex FPGAs, or to infer typical 
asynchronous reset FFs if targeting another tech- 
nology. The number of taps are fixed, however 
the tap points and LFSR length are parameter- 
ized. 


Conclusion 


The Virtex architecture is very efficient for creat- 
ing PN generators by using the Virtex Shift 
Register LUT (SRL). The SRL can also be used In 
many other applications such as pipeline bal- 
ancers, filters, dividers, and waveform genera- 
tors. In large systems, such as CDMA, the overall 
FPGA utilization can be reduced considerably by 


,srl2_i[Width-1:| tap4+1]} 


0; 
= {fsr_in_ 
rl2_i[|_tap4],srl1_ifl tap4-1:1]} 


code as it is intended to be used for reference purposes only. 
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When targeting Virtex,all the latest synthesis tools (Leonardo, 
Synplify, and FPGA Express) will infer the SRL16E resulting in a very 
code to infer FFs or Virtex SLR16E elements, may not be supported 
by all synthesis tools. Controlling the compiler flow can be done by 

un-commenting the first line. (This can also be done from a top 
level module). Only minimal simulations have been run on this 


if (ShiftEn) begin 


srl2 i< 
srl2 i < 
sll i < 





smaller, fewer, and less expensive parts. With 


only a basic understanding of the SRL, along 
with today’s Virtex-friendly synthesis tools, these 
Savings can be accomplished easily and without 


taking advantage of the SRL, which can lead to 
sacrificing code portability. # 


‘else // compiler directive, if not defined,will infer SRL16. 


always @(posedge clk) begin 


endmodule 
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Post Synthesis 





Verification 





. \4 





for Virtex FPGAs 


For large designs especially, verification throughout 
the design flow will save you time and effort. 


Nij 


S FPGAs grow bigger and faster It 
becomes increasingly important to veri- 
fy your designs; this saves you time and 
produces better designs. Verification after syn- 
thesis should be part of the design process 
because this ensures that you pass the correct 
netlist to the Xilinx place and route tools. Also, 
you can debug your designs faster, whether you 
are using an RTL netlist (RTL verification) ora 
synthesized netlist (post synthesis verification). 





Post Synthesis Verification 


A synthesis tool usually writes a netlist based on 
the UNISIM library. The cells in the library are 
modeled well for both simulation and synthesis. 
For example in the verilog UNISIM library, the 
LUTs (look up tables) are modeled using UDP 
(user defined primitives). This can speed up your 
design simulation considerably, and because 
most of the combinational logic will be mapped 
to LUTs, overall simulation will also be fast. In 
Short, if the synthesis tool can write a 

Verilog/ VHDL netlist with LUT cells and their 
INIT attributes, verification will be very accurate 
and fast. 


Enhancements in Leonardo Spectrum 


Traditionally, verification was performed on the 
Verilog or VHDL netlist generated by the Xilinx 
place and route tools. Thanks to new functional- 


NA 
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ity in the latest release of LeonardoSpectrum 
from Exemplar Logic, gate-level verification is 
now supported prior to place and route, using 
the Xilinx UNISIM simulation library. 


Procedure for Using Gate-level Simulation 


A special variable in LeonardoSpectrum must be 
set, to turn on this feature: 


xi_write_init_on_luts (default is FALSE) 


This variable must to be set to “TRUE” before 
writing out the Verilog/ VHDL netlist. The vari- 
able can either be set in the GUI, using Tools -> 
Variable Editor, or in the interactive shell you 
can type: 


set xi_ write_init_on_luts TRUE 
Verilog Example 


Here is a simple Verilog example, to demonstrate 
the feature. The RTL design is synthesized in 
LeonardoSpectrum and a Verilog netlist (with the 
above variable set to TRUE) is written out. The 
synthesized netlist is simulated using the MTI 
(Modeltech) Verilog simulation tool. The design 
output is the registered value of A and B and C. 
The register clock is four times slower than the 
main clock; it uses CLKDLL to divide the main 
clock by four. The output waveform is shown in 
Figure l. 


Notice the INIT properties being used to con- 
figure the LUT cells of the synthesized netlist. 


RTL Design 


// module defintion of CLKDLL 
module CLKDLL ( CLKIN, CLKFB, RST, CLKO,CLK90,CLK180,CLK270, 
CLK2X,CLKDV, LOCKED 


parameter CLKDV_DIVIDE = "2.0" ; 

parameter DUTY_ CYCLE CORRECTION = "TRUE"; 

input CLKIN, CLKFB, RST ; 

output CLKO,CLK90,CLK180,CLK270,CLK2X,CLKDV, LOCKED ; 
endmodule // CLKDLL 


module slow_clk_ dll (CLKOUT, CLKIN, RST); 

input CLKIN, RST; 

output CLKOUT: 

wire I]BUFG_OUT, BUFG_A_IN, BUFG_A_ OUT, BUFG B IN, BUFG_B_OUT; 

IBUFG Ub_ibufg ( .I(CLKIN),.O(IBUFG OUT) ); 

CLKDLL Ub_clkdll ( .CLKIN(IBUFG OUT),.CLKFB(BUFG A OUT),.RST(RST), 
-CLKO(BUFG_A_IN),.CLKDV(BUFG_B_IN) ); 

// divide the input clock by 4 

defparam Ub_clkdll.CLKDV_ DIVIDE = "4.0"; 

BUFG Ub_bufgA ( .| (BUFG A_IN),.O(BUFG_A OUT) ); 

BUFG Ub_bufgB ( .| (BUFG B_IN),.O(BUFG_B OUT) ); 

assign CLKOUT = BUFG_B_ OUT; 

endmodule // slow_clk_dll 


module simple (A,B , C, RST, OUT, CLK): 
input A, B, C, RST, CLK; 
output OUT; 
reg OUT; 
wire SLOW_STEADY_ CLK; 
Slow_clk_dll simple clk (SLOW STEADY CLK,CLK,RST); 
always @ (posedge SLOW_STEADY_CLK) 
begin 
if (RST) 
OUT = 1'b0; 
else 
OUT=A &B&C; 
end 
endmodule // simple 


/simple_system/AST_ Ib 
/simple_system/A_lb 
/simple_system/B_lIb 
/simple_system/C_lIb 

/simple_system/CLK_Ib 

/simple/systemU1/SLOW_STEADY_CLK 


Synthesized Netlist 


module simple ( A, B, C, RST, OUT, CLK ) ; 
input A , B, C, RST, CLK; 
output OUT ; 
wire SLOW_ STEADY CLK,simple clk BUFG_B_IN, simple_clk_BUFG_A_OUT, 
simple_clk_BUFG A_IN, simple _clk_IBUFG_ OUT, A_int,B_ int,C_int, 
RST_int,OUT_dup0,nx53,nx54; 
wire [4:0] \$dummy ; 
IBUFG simple _clk_Ub_ibufg (.0 (simple clk IBUFG OUT),.I (CLK)) ; 
CLKDLL simple clk _Ub_clkdll (.CLKO (simple clk BUFG A_IN),.CLK90 ( 
\$dummy [0]),.CLK180 (\$dummy [1]),.CLK270 (\$dummy [2]),.CLK2X ( 
\$dummy [3]),.CLKDV (simple clk BUFG B_IN),.LOCKED (\$dummy [4]),.CLKIN ( 
simple_clk_IBUFG_OUT),.CLKFB (simple clk _BUFG A _OUT),.RST (RST_int) 
I 
defparam simple_clk_Ub_clkdll.CLKDV_ DIVIDE = 4.0; 
defparam simple_clk_Ub_clkdll.DUTY_ CYCLE CORRECTION = "TRUE"; 
BUFG simple_clk_Ub_bufgA (.0 (simple clk _BUFG_A_OUT),.I ( 
simple_clk_BUFG A_IN)); 
BUFG simple_clk Ub bufgB (.0 (SLOW_STEADY CLK),.I (simple clk_BUFG_B_IN)) ; 
OBUF OUT obuf (.0 (OUT),.I (OUT dup0)) ; 
IBUF RST_ibuf (.0 (RST_int),.1 (RST)) ; 
IBUF C_ibuf (.O (C_int),.1 (C)) ; 
IBUF B ibuf (.0 (B_int),.1 (B)) ; 
IBUF A_ibuf (.0 (A_int),.I (A)) ; 
FDR reg_OUT (.Q (OUT dup0),.D (nx54),.C (SLOW _STEADY_CLK),.R (nx53)) ; 
LUT2 1x46 (.0 (nx53),.10 (C_int),.12 (RST_int)) ; 
defparam ix46.INIT = 4'hD; 
LUT2 1x47 (.0 (nx54),.10 (A_int),.I1 (B_int)) ; 
defparam ix47.INIT = 4'h8; 
endmodule 
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Figure 1 - Output waveform from M odeltech. 


Conclusion 


With LeonardoSpectrum you can verify the cor- 
A more complete version of this article, with a test bench,is available at: 
rectness of your netlist before you go to place http://www.exemplar.com/support/appnotes, html. 
and route, and get high quality results for your 
Virtex FPGA designs. # 
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Using the M odelSim FPGA 


Library M anager 





Using the new FPGA Library Manager will improve your simulation time ® 
easily building Xilinx FGPA libraries for use within ModelSim. 


by Joe Rodriguez, Technical Marketing Engineer, Model 
Technology Inc., joer@model.com 


odelSim is a mixed-language, single- 
kernel simulator, allowing you to 
simulate Xilinx FPGA instances 
implemented in Verilog, together with other 
instances in VHDL, in the same simulation run. 
You have flexibility in your choice of HDL lan- 
guage, and you can easily build the simulation 
library for your chosen Xilinx FPGA (and HDL 
language) with the FGPA Library Manager which 
Supports simprim, unisim, and LogiBLOX simula- 
tion libraries in both Verilog and VHDL for all 
Xilinx FPGA families. 





Using the FPGA Library Manager : 


The new ModelSim FPGA library manager guides 
you through the process of compiling the FPGA 
libraries provided by Xilinx. These compiled 
libraries can then be used with your design to 
simulate with ModelSim. The source code for the 
Xilinx libraries is included with the Alliance 
Series Software, and is referenced by the 
“XILINX” Environment Variable. 


Here are step by step instructions for using 
the Library Manager: 


e Invoke ModelSim and go to a working direc- 
tory where you want to compile the FPGA ° 


AO 


libraries (this can be where your design 
source files are located). A welcome banner 
will appear. This new banner contains several 
new features, including a new Project Wizard. 
The Project Wizard is documented in the 
ModelSim Reference Manual, and in the 
Tutorial which has an example project. 
Dismiss the Welcome Banner, continue to 
ModelSim. 


From the main ModelSim window change 
directories. Use File >Change Directory to 
Browse for your working directory 


From the main window command line enter: 
vlib work 


Select the FPGA Library Manager which will 
build the FPGA library. Use Design > FPGA 
Library Manager. 


Use the Browser to select the Xilinx TCL 
script. (ModelSim uses TCL as a scripting lan- 
guage.) The Library manager uses a support 
file that resided in the ModelSim_install_direc- 
tory/ contrib. These scripts will be updated as 
the Xilinx parts list evolves. See the 
Additional Information section below for 
updated script downloads. Use Browse > 
Select fpgavendor xilinx.tcl >Open > 
Next (Please refer to Figure 1 “ModelSim X#L 
INX FPGA Library Manager Window”.) 


Select a ModelSim project initialization file 


“Fis. Liaw Manager sie 


(which contains default settings 
for ModelSim). The Xilinx root 
directory value is from your sys- 
tem environment variables. 


e Choose your HDL language (VHDL 
or Verilog). If you have a VHDL 
testbench, you can run a Verilog 
description of your design with 
ModelSim, if the pin names match 
exactly (d[0:31] does not match 
di1,d2....d31) and you are using 
STD LOGIC at the lO (ModelSim 
will map VHDL to Verilog 
strength). 


e Select the Xilinx FPGA Library. 
The Xilinx Library source code 
that gets compiled is from the 
Xilinx root directory, which is read 
from your system environment 

Figure 1: ModelSim Xilinx FPGA library manager window. variable. The example uses the 

XC5200 Family. The Maps To entry 

is aname of the ModelSim library 

you wish to use. This can be any 
name you wish, default is XILINX. 
This physical name can be 
ee mapped to the needed logical 
an i name required by the source code. 


D:/xcell/xilinx_vhdl/ Xilinx i 
aes || © Select Write Build Script; the 
i tnstenses i default path name is the current 


# Project File: D:/59/win32/../modelsim.ini 


puts "Creating Library...” ; directory. (ModelSim is a full fea- 


vlib D:/xcell/xilinx_vhdl/ Xilinx 


Snir ayer cre Ree ee || tured simulation tool that can be 
een oo homered ees ae run in Ul mode, command line 
Kroc _mvoche etupeia di/xiineai/vnai/ive/eiupeine/eiuneia VETALVEa mode, or batch mode. The 
SS ModelSim FPGA Library Manager 
Figure 2: ModelSim Xilinx FPGA library script. can create a script that can be 
used to re-compile the FPGA 
library.) The TCL script can be 
seen in Figure 2: the vlib com- 
mand creates a ModelSim library, 


vcom is the VHDL compiler, and 








| & source_edit - D:/xcell/xilinx_vhdl/buildxilinx.do 





i ANZ 


AO 


Main Window -> Open ->Open Source, select 


|, ModelSim EE/Plus 5.3 





buildxilinx.do. 
File Edit Design View Fun Macro Options Window Help 





The library is now available for use 
with your source files. 






cd 0: cell siling_vhdl 

fH reading modelsim. iri 
A Executing: # FPGA Library Manager generated library build script for: 
fH Esecuting: # Vendor: vilire 

#HEsecuting: # Timing: = VHDL os . 
HExecuting: HMaps To: D:/xcellsiing_vhdl/siline Ad d Iti Oona | | nfo rm atl on 
#HExecuting: # Farm = =CH200 

fH Executing: # GSR: With GSA 


ESE: 


}# Executing: # Testbench: For updates to the Xilinx FPGA vendor 
fH Executing: # Instance: ,; 
HH Executing: # Project File: 0: /53/wins2/../modelsim. ini compile scripts, go to: 


Executing: puts Creating Library..." 

4 Creating Library... 

# Executing: vlib D:/xcell/siliny_vhdl/*iling htto://www.model.com/resources/fpgaliomgr.htm| 
Ht Executing: puts "Creating Mapping to Library..." 

# Creating Mapping to Library... 


# Executing: ymap simprim 0: 4scellésiling_ vad Ailing Fora com pl ete A ppl ication Note 

HA Modifying 0: /5S/wins2e.modelsin. ini . . _ ; 

iH Executing: puts “Compiling source for Slings, WHOL, Sinprim..." ModelSim 5.2 With Xilinx Alliance 2.1 
fH Compiling source for Sil, “WHOL, Sirnprirn... 

HH Executing: voor -work simprin d: Asin] evhdlsrc/simprims/simprim_ components. vid showi Ng step by step instructions for 
# Model Technology ModelSim EE 5.3 Compiler 1999.09 Sep 11999 : : : 
Gaede using ModelSim to compile and simu- 


Ht -- Loading package std_logic_1164 

}# -- Loading package vital_timing 

#-- Compiling package vcomponents 

#BeExecuting: voom -work simprin dling] vhdd‘srcsimprinssimprim Ypackage. vhd ~ 
# Model Technology ModelSim EE vcom 5.3 Compiler 1999.09 Sep 1 1999 http://www.model.com/pat/113_xilinx_21.pdt 
}# -- Loading package standard 

iH -- Loading package std logic 1164 | 


JeNo Design Loaded> | ; | ve 


Figure 3: Main ModelSim window. 


late any of your Xilinx designs, go to: 





For a list of all MTI Application 
Notes, including ModelSim 5.2 with 
Alliance 1.5 and example circuits for 


vmap maps the physical location to the logi- use with Application Notes, go to: 


cal name used in your VHDL source code. 
This script can now be used to build the http://www.model.com/support/technote/index.html 
library without the use of the FPGA Library 

Manager. See the MT! Application Notes fora 


full description of the use of scripts with Conclusion 
ModelSim. The new ModelSim FPGA library manager 

e Select Build Library. The Main Window removes the question of how to compile the 
scrolls messages indicating the library has Xilinx FPGA libraries, so you can focus on the 
been built as shown in Figure 3. When the verification of your Xilinx design. © 


library compilation is complete an informa- 

tion window will appear. Dismiss the library 
compiled information window, and Exit the 

FPGA Library Manager. The ModelSim build 
script is shown in Figure 2. 


FPGA System 


Simulation and Synthesis 


Using Synopsys VCS 24 FPGA Compiler II 


This HDL design methodology can help you use the largest Virtex 
FPGAs with a minimum amount of time spent on synthesis, simula 


tion, and verification. 


ynopsys has combined its powerful logic 

synthesis technology with innovative 

architecture-specific optimization technol- 
ogy to address the needs of FPGA designers who 
are now adopting an HDL methodology. FPGA 
Compiler II delivers powerful architecture-specif- 
ic synthesis capabilities with features such as 
behavioral re-timing and pipelining capability. 
Synopsys VCS (Verilog Compiled Simulator) pro- 
vides a fully-featured implementation of the ver- 
ilog language as defined in the IEEE Standard 
Hardware Description Language (IEEE Std 1364- 
1995). 


VCS ts specifically designed to simulate large, 
complex designs faster than any other Verilog- 
HDL simulator. VCS supports interfaces to a varli- 
ety of other simulators and models, including 
(but not limited to) user PLI applications con- 
forming to IEEE Std 1363-1995, delay calcula- 
tors, SDF delay annotation, LMG Smatmodels, 
and the LMSI hardware modeler. 


The combination of the FPGA Compiler Il 
synthesis tool and the VCS simulator provides a 
Simple and accurate design and verification flow 
that significantly reduces your total development 
time. 


C1 





by Srikanth Vijayaraghavan, Applications Consultant, Synopsys, 
raghavan@synopsys.com 


Detailed Design Flow 


The steps involved in taking a design from an 
RTL description to a production FPGA are sum- 


Module reg] (clk, reset, din, dout); 
input clk,reset; 

input din; 

output dout; 


wire clk,clk_ enbl, reset; 


wire din; 
reg dout; 


always@ (negedge clk or posedge reset) 
if (reset) 

dout = 0; 
else 

dout = din; 


endmodule 


Example 1 - RTL description of a simple flip-flop. 


marized in Figure 1. These steps are explained in 
detail using the RTL description of a flip-flop 
Shown in Example 1. After synthesizing the RTL 
code for this flip-flop using FPGA Compiler Il, 
you can automatically generate a functional 
Verilog simulation netlist as shown in Example 
2. FPGA Compiler Il is capable of synthesizing 
the design, either by flattening the design com- 
pletely, or by preserving the complete hierarchy. 


// Synopsys FPGA Compiler II 
// automatically generated file 


// Author: raghavan 


// Program:FPGA Compiler II 


// Version:3.2.0.4206 


module FDC_1 (Q ,D ,C ,CLR ); 


output Q ; 

input D ; 

input C ; 

input CLR ; 

wire synch_enable ; 
reg Q | 


always@( negedge C or posedge CLR ) 


begin 
if (CLR ) Q = 1’b0; 
else Q =(D); 

end 


assign synch_enable = ( 1’b1 ); 


endmodule 


module IBUF ( 0 |I ); 
output O ; 
input | ; 
assign O = (1); 
endmodule 


module OBUF_S 12 (0 
output O ; 
input | ; 
assign 0 = (1); 
endmodule 


module regl ( clk ,reset 
input clk ; 
input reset ; 
input din ; 
output dout ; 


wire N_clk ; 
wire N_ reset ; 
wire N_ din; 
wire N_ dout ; 


Ale 


din ,dout ): 


FDC_1 dout_reg (.CLR (N_reset),.Q (N_dout),.C (N_clk),.D (N_din)); 


IBUF C_clk (.1 (clk),.0 (N_ 


clk)); 


IBUF C_reset (.1 reset),.O(N_ reset ) ); 
IBUF C_din (.1 (din),.0 (N_ din)); 


OBUF S 12 


C_dout (.1 (N_ dout),.0 (dout)); 


Endmodule 





Example 2 - Post synthesis functional netlist 
generated by FPGA Compiler Il. 


The netlist can be simulated in VCS like any 
other Verilog file. FRGA Compiler Il maintains 
the port names at the module level and therefore 
debugging through the hierarchy Is very easy. 


Assuming you have a testbench for the 
design module named test_regl.v, a simple com- 
mand line script for simulation in VCS will look 
as follows: 


vcs -RI -Mupdate regl.v test_regl.v -o regl.simv -! reg1.log 


Where: 


e -RI is for simulating and bringing up the 
XVCS Debugging debugging GUI 
automatically. 


e -Mupdate is to enable incremental compile. 


e -o is to provide a distinct name for the exe- 
cutable file; default name is simv. 


e -lis to provide a distinct name for the log file 
produced during compile. 


Once the functionality of the design is veri- 
fied, the EDIF equivalent to this Verilog netlist is 
generated using FPGA Compiler Il. The timing 
constraints entered in the FPGA Compiler II GUI 
can be exported into a spec file (.ncf), which is 
understood by the Xilinx software tools. The 
Xilinx software uses this EDIF netlist and the .ncf 
constraint file to place and route the design. 


If the design routes successfully, you can 
write a Verilog simulation netlist in terms of gate 
cells, and also a delay file (.sdf, Standard Delay 
Format). A part of the delay file that corresponds 
to the gate level netlist is shown in Example 3. 
This .sdf file should be included during simula- 
tion to back annotate the original delays into the 
design. 


The delay values need to be back annotated 
through the PLI interface in VCS. The .sdf file is 
called from the gate-level netlist through the 
“$sdf_ annotate” utility. For performing a gate- 
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Figure 1 - Detailed design f.low for Xilinx FPGA’s 


level simulation, you need to first create 
a table file. This table file will list all the 
PLI tasks that need to be included. The 
“simprims” directory inside the Xilinx 
installation contains the Verilog descrip- 
tion of all the library cells (.vmd exten- 
sion). These descriptions contain the 
timing checks for the setup and hold 
time violations. Annotating the original 
delay values from the .sdf file during 
Simulation performs these checks. 


Now create a pli.tab file, with the fol- 
lowing content: 


$sdf_ annotate call=sdf_annotate call 
acct=mp,prx:reg_gate+ 


Where: reg_gate is the name of the 
top level module 


Now, to perform a gate level simulation, 


(TIMESCALE 1 ps) 
(CELL 
(CELLTYPE*X EF’) 
(INSTANCE dout_reg) 
(DELAY 
(ABSOLUTE 

(PORT IN (1948:1948:1948) (1948:1948:1948)) 
(PORT CLK (1520:1520:1520) (1520:1520:1520)) 
(PORT RST (0:0:0) (0:0:0)) 
(IOPATH CLK OUT (887:887:887) (887:887:887)) 
(IOPATH SET OUT (887:887:887) (887:887:887)) 
(IOPATH RST OUT (887:887:887) (887:887:887)) 


(TIMINGCHECK 

(SETUP (negedge RST) (posedge CLK) (479:479:479)) 
(SETUP (posedge IN) (posedge CLK) (195:195:195)) 
(SETUP (negedge IN) (posedge CLK) (195:195:195)) 
(HOLD (posedge IN) (posedge CLK) (0:0:0)) 

(HOLD (negedge IN) (posedge CLK) (0:0:0)) 

(WIDTH (negedge CLK) (3456:3456:3456)) 

(WIDTH (posedge CLK) (3456:3456:3456)) 

(WIDTH (posedge RST) (3456:3456:3456)) 


Example 3 - SDF file generated by Xilinx software. 





you can use a Sample script as follows: 


vcs -RI -Mupdate reg_gate.v test_reg.v 
-0 gate _reg -| gate _reg.log \ 
-y $XILINX/verilog/src/simprims \ 
+libext+.vmd+ \ 
-P pli.tab 


Where: 


e -y stands for the library directory. 


¢ -+Hibext+vmd+ stands for all the files with 
extension .vmd. 


e -P stands for pli table file. 


Conclusion 


The Synopsys FPGA Compiler Il and VCS provide 
an easy and intuitive HDL design methodology, a 
seamless design flow, and high level control 
within the design process. In addition, using 
FPGA Compiler Il gives you the power to effec- 
tively use Xilinx Virtex devices with the highest 
quality results. # 





digital SET-TOP.boxes 


An ldeal Application 


fr SPARTAN FPGAS 


Digital set top boxes are a catalyst for consumer-based computing, 
and they hasten the shift towards a networked home. 


by Rebecca Burr, Manager of Market Analysis, 
Xilinx, burr@xilinx.com 


ccording to market 
researchers, the digital set- 
top box (DSTB) market is 
projected to grow at a compound x 
annual growth rate approaching 7 
17% over the next few years. Production is antic- 
ipated to double between 1999 and 2002, to over 
forty million units a year. 


e E-commerce for grocery shopping, Web 
browsing, and banking. 





e Infotainment such as interactive games, Video 
on Demand, on-line casinos. 





e E-mail. 

Videoconferencing. 
¢ Downloading music files from the internet. 
e Recording television programs. 

Today, most set top boxes deliver minimal 

functionality, and the market remains fragment- Market Structure 
ed with varying levels of features and disparate 
standards. In addition, cable suppliers are seek- In the set top box market, a small number of 
ing to expand services and features, and include producers dominate. However, standards still 
the functions currently offered by other con- 
sumer appliances, to justify increased fees. This 
is an ideal application for the flexibility, low cost, 
and time-to-market benefits of Spartan FPGAs. 


Possible Features 


Some of the possible features that can be offered 
by DSTBs: 


e Phone caller ID displayed to the television 
screen. 





market is essentially a subscriber-based business 
where the service providers furnish the hardware 
for free. Recently, the digital satellite industry 
also began adopting this approach by offering a 
rental option for set-top boxes. 


The Collective DSTB Market 


The DSTB market is composed of three compet- 
ing technologies: 


e Digital Terrestrial systems use conventional 
antennas, and are already in limited use in 
Europe, with broader service launches expect- 
ed over the next few years. Japan also expects 
to launch Digital Terrestrial services in the 
2003 timeframe. Because it leverages the 
existing infrastructure, this technology is 
expected to exhibit explosive growth. 


e Digital Cable is a conversion of existing ana- 
log cable distribution systems, and broadcast- 
ers have been swift to implement these stan- 
dards. 


e Digital Satellite technology is still in its 
infancy, offering lower cost distribution, ser- 
vice delivery to thinly populated regions, and 
ease of upgradeability. Standards for Digital 
Satellite systems are not consistent between 
broadcasters. 


Conclusion 


DSTB designers must optimize for both price and 
performance in an increasingly competitive mar- 
ketplace. Plus, they must provide more function- 
ality and create robust designs that offer flexibili- 
ty for varying standards and for backward and 
forward compatibility. This is an impossible task 
for ASICs, and that’s why the Spartan FPGA fam- 
ily is a key component of any DSTB strategy. # 


Q uestions 


SUPPORT. XILINX. COM 


Answers 


From the Xilinx Applications Engineering Staff 


Virtex I/Os 


How do | pull the I/O pins to 5 Volts using external 
pullups? 

To pull up the I/O pins to 5V externally, only three I/O 
standards are allowed: LVTTL, LVCMOS, and PCI33_5. 


The internal I/O pullup can be considered to be a 
50K resistor to Vcco (for 3.3-V or 2.5-V devices). If you 
try to pull an I/O to a voltage higher than Vcco, you 
need to do so with a resistor, with a smaller value 
than 50K. The devices have circuitry to disable the 
internal pullup if the I/O is pulled higher than about 
Vcco +0.7V (a threshold voltage higher than Vcco), so 
if you pull an I/O up to 5V, there will be no static cur- 
rent into Vcco. But if you don’t pull up the I/O past 
Vcco +0.7V, then the internal pullup remains enabled 
and will “fight” with the external pullup. 


Our recommendation is to use a 4.7K pullup resis- 
tor, but any value less than 4.7K will also work. 


Software Installation 


What do | do if my Alliance Series or Foundation Series 
2.1i installation does not complete as a result of one of 
the following issues: 


The splash screen appears, then disappears with- 
out an error message. 


An unexpected error occurs during setup. 


There may be several reasons for either of the 
error messages to appear. In general, ensure that you 
have administrative privileges and that there is plenty 
of hard drive space on the destination drive. 
Additionally, a re-boot is sometimes needed to release 
any locked Windows DLLs. 


If you have done the above, and the installation 
still fails, the most likely problem has to do with the 
way the registry settings for certain environment vari- 
ables are interacting with the 2.1i installer. Typically, 


by Rohit Sawhney, Product Applications Manager, Xilinx, rohit@xilinx.com 


simply resetting these variables will over-write the 
registry entry that is causing this problem, and allow 
the installer to succeed. 


The variables that have been seen to exhibit the 
problem are: PATH, TEMP, and TMP. 


Win9x: Make sure these variables are listed in 
your autoexec.bat file. 


WinNT: You can check your environment by exe- 
cuting: 
‘Start -> Settings -> Control Panel -> System -> Environment Tab’ 


In the System Variable section, there should be a 
PATH variable listed. In the User Variable section, 
there should be both TEMP and TMP variables. Re- 
updating each of these variables will correct the set- 
ting in the registry. 


If there is no PATH variable listed in the User sec- 
tion, then create one. To do this: 


1. Click on the Variable line and type in PATH. 
2. Click on the value, and type in %PATH%. 


By doing the above, the registry entries should get 
corrected, allowing the installation to succeed. For 
further information please reference: 


http:/ / support.xilinx.com/ techdocs/ 7074.htm 


http:/ / support.xilinx.com/ techdocs/ 7362.htm 


CORE Generator 


Are there any cores to speed up the implementation of 
Virtex designs? 

The following cores are either included in the Xilinx 
2.1i software release, or can be downloaded from the 
Xilinx CORE Generator Cores and IP Updates page: 
(http:/ / www.xilinx.com/ ipcenter/ 

coregen/ updates.htm #updatesCurrent) 


The following cores are included in the 2.11 Release 
CD: 


Dynamic Constant Coefficient Multiplier. 


Divider. 


Block Memory modules (single and dual port). 


The following cores can be downloaded from the 
Xilinx CORE Generator Cores and IP Updates page: 


Gate functions (AND, NAND, OR, NOR, XOR, 
XNOR, INVERTER). 


Multiplexer functions (bit, bus, slice BUFE/ BUFT). 


Register functions (flip-flop and latch based). 
Parallel Multiplier (pipelined and combinatorial). 
Sine/ Cosine Lookup TAble. 


Distributed Memories (single and dual port RAM 
and ROM). 


Adder/ Subtractor. 
Accumulator. 
Comparator. 

Binary Counter. 

Decoder. 

FD-Based Shift Register. 
RAM-based Shift Register. 
Two’s Complement. 


Numerically Controlled Oscillator (Single and Dual 
Channel) 


Distributed Arithmetic FIR Filter. 
Asynchronous FIFO. 

FFT and Inverse FFT (16-, 64-, 256-, and 1024- 
point). 


Note: All Xilinx CORE Generator LogiCORE modules 
that support the Virtex architecture also support 
Virtex-E and Spartan-ll architectures. 


Synthesis 

How can | instantiate a CLKDLL using Exemplar Spectrum 
or Synplicity? 

Currently, CLKDLL has to be instantiated or manually 
inserted in Exemplar and Synplicity. 


A sample design and procedure for CLKDLL inser- 
tion in Exemplar Spectrum is documented in the 
following solution: http:/ / www.xilinx.com/ tech- 
docs/ 7737.htm 


A sample design for CLKDLL instantiation in 
Synplicity is documented in the following solution: 
http:// www.xilinx.com/ techdocs/ 8144.htm 


How can | infer a BlockRAM in Exemplar or Synplicity? 


Both Exemplar Spectrum and Synplicity now support 
Virtex BlockKRAM (a fully synchronized RAM) infer- 
ence. 


Xilinx Solution 7929 (http:// www.xilinx.com/ tech- 
docs/ 7929.htm) provides VHDL/ Verilog example 
for Exemplar Spectrum. 


Xilinx Solution 2508 (http:/ / www.xilinx.com/ tech- 
docs/ 2508.htm) provides VHDL/ Verilog example 
for Synplicity. 

Note: The BlockRAM inference example provided in 
XCELL 32 for Leonardo Spectrum was incorrect. 


How can | infer a ROM in Synplicity? 


One of the new features in Synplify 5.3 is ROM infer- 
ence. Earlier versions of the Synplify compilers were 
able to infer ROM tables. Synplify 5.3 now maps these 
inferred ROMs to Xilinx ROM primitives (ROM16X1 
and ROM 32X1) with the use of an attribute called 
syn_romstyle. 


Xilinx Solution 8183 shows how to infer these 
ROMs for the 4K and Virtex families in VHDL/ Verilog: 
http:// www.xilinx.com/ techdocs/ 8183.htm. 


Simulation 
How do | use glbl.v module in the Verilog simulation? 


In the 2.11 Alliance Series, the general procedure for 
specifying global signals for the Verilog simulation 
flow involves defining the global signals with the 
$XILINX/ verilog/ src/ glbl.v module. This module 
allows a global signal to be modeled as a wire ina 
global module. 


The glbl.v module connects the global signals to 
the design, which is why it is necessary to compile 
this module with the other design files and load it 
along with the toplevel.v file or the testbench.v file for 
simulation. 


Configuration & JTAG/ Boundary Scan 


What are the supported Xilinx cable, software, and device 
combinations? 

The following combinations are supported, as 
described in http:/ / support. xilinx.com/ tech- 

docs/ 8097.htm: 


» MultiLINX cable with Hardware Debugger 
v2.11 (or later): 


Supports slave serial configuration of XC3000A, 
Spartan/ XL, XC4000E/ EX/ XL/ XLA/ XV, and 
Virtex/ E devices. 


SelectMAP configuration on Virtex/ E devices. 


Readback verify supported for XC4000E/ EX/ XL/ 
XLA/ XV, XC9500/ XL/ XV, Spartan/ XL, and 
Virtex/ E devices. 


. MultiLINX with JTAG Programmer v2.11 sp3 
(or later): 


Supports JTAG configuration of XC1804, 
XC4000E/ EX/ XL/ XLA/ XV, XC9500/ XL/ XV, 
Spartan/ XL, and Virtex/ E devices. 

Supports Readback-Verify of the XC9500/ XL/ XV 
devices. 


. Parallel Cable III with Hardware Debugger 
v2.1i (or later): 


Supports slave serial configuration of XC3000A, 
XC4000E/ EX/ XL/ XLA/ XV, Spartan/ XL, and 
Virtex/ E devices. 


. Parallel Cable III with JTAG Programmer 
v2.11 sp3 (or later): 


Supports JTAG configuration of XC1804, 
XC4000E/ EX/ XL/ XLA/ XV, XC9500/ XL/ XV, 
Spartan/ XL, Virtex/ E devices. 


Supports Readback-Verify of the XC9500/ XL/ XV 
devices. 


. XChecker with Hardware Debugger v2.1i (or 
later): 


Supports slave serial configuration of XC3000A, 
XC4000E/ EX/ XL/ XLA/ XV, Spartan/ XL, and 
Virtex/ E devices. 


Supports Readback-Verify and Readback-Capture 
of XC4000E/ EX/ XL/ XLA/ XV, and Spartan/ XL 


devices with a configuration bit stream of 250,000 


bits or less. 


. XChecker with JTAG Programmer v2.1i sp3 
(or later): 


Supports JTAG configuration of XC1804, 
XC4000E/ EX/ XL/ XLA/ XV, XC9500/ XL/ XV, 
Spartan/ XL, Virtex/ E devices. 


Supports Readback-Verify of the XC9500/ XL/ XV 
devices. 


Where can | find information on performing J TAG config- 
uration on a Virtex device? 

See Application Note 139 (Xapp139) Configuration and 
Readback of Virtex FPGAs Using (JAG) Boundary-Scan 
at: http:// www.xilinx.com/ xapp/ xapp139.pdf. 

What cable should be used with the Coolrunner ISP pro- 
grammer? 

The Xilinx Parallel Ill Cable should be used. Please ref- 
erence: http:/ / support.xilinx.com/ techdocs/ 7588.htm. 
Which CoolRunner devices support ISP or Boundary Scan 
Operations? 

The Coolrunner ISP and Boundary Scan support is list- 
ed in the following reference: 

http:/ / support.xilinx.com/ techdocs/ 8173.htm 


support.xilinx.com 


What recent improvements have been made to the sup- 
port.xilinx.com search engine? 

A number of improvements have been made to our 
Web search engine: 


e The first improvement was to update the underly- 
ing search algorithm. Previously we were AND-ing 
search terms together, which returned very precise 
results but often made it difficult for users to find 
what they were looking for. We decided to imple- 
ment a more Internet friendly algorithm by using 
an ‘ACCRUE’ operation. This allows user queries 
to be scored, returning documents matching the 
highest number of keywords at the top of the list. 
Documents containing only one or two keywords 
would be returned at the bottom. 


e The second improvement was to collect our older 
answer records into a separate archive. When new 
Xilinx users search our database, they no longer 
have to worry about sorting through older answer 
records to find the most current information. 
However, you will still have access to this older 
information. 


e Finally, we’ve included the ability to search our 
software manuals from the same interface. It is 
now possible to search the Answers Database and 
online software documentation at the same time. # 


Xilinx Trade SNOW Programs 


Attend these events and see for gurself 
Xilinx technology at work. 





by Darby Mason-Merhant, Trade Show Manager, Xilinx, darby@xilinx.com 


ilinx started the year with two new cations such as telecom, communications, con- 
. He * 
requirements-Spartan-I| FPGAs and are everywhere and so is Xilinx! ® 





CoolRunner XPLA3 CPLDs. At the Portable 
Design 2000 and Wireless Symposium 2000 


events, Xilinx demonstrated how our technology Year 2000 Worldwide Xilinx 

is “Spanning the Low Power Spectrum” with new Trade Show Schedules 

wireless connectivity and MP3 Player demonstra- Year 2000 European Trade Show Schedule 

tions. Nov 2000 Electronica 2000 Munich,Germany 
You can also expect to see numerous new Year 2000 South East Asian Trade Show Schedule 

partnerships and solutions, demonstrated at Hela 22-28 Heaney Guanzhou,Ching 

more shows and events worldwide. You'll also March 27-28 IC 2000 Shanghai,China 

see where Xilinx is making a difference in appli- March 20-21 IC 2000 Beijing, China 


May 3-4 IIC Taipel Taipei, Taiwan 
October 2000 EDA&T Hsinchu, Taiwan 


Year 2000 Worldwide Xilinx October 2000 EDA&T Beijing, China 


Trade Show Schedules 


Year 2000 North American Trade Show Schedule 
Jan 25-26 Portable Design 2000 San Diego, CA 


Year 2000 Japanese Trade Show Schedule 
Jan 27-28 EDA Techno Fair 2000 Tokyo, Japan 


Nov 2000 Micon System Tool Fair 2000 Tokyo, Japan 
Feb 22-24 Wireless Symposium 2000 San Jose, CA 


Feb 9-11 FPGA Conference 2000 Monterey, CA 
March 14 Synopsys User’s Group 2000 San Jose, CA 
March 21-22 IP2000 Santa Clara,CA 
April 10-12 DSP Spring Conference 2000 San Jose, CA 
April 2000 FCCM Conference 2000 Napa,CA 


For more information about Xilinx Worldwide Trade 
Show Programs, please contact one of the following 
Xilinx team members or see our website at: 

http:// www.xilinx.com/ company/ tradeshows.htm 


M ay-Dec Embedded Computing Shows US & Canada 


e US Shows: Darby Mason-Merchant at: darby@ 
xilinx.com or Evangeline Tanner at etanner@ 
xilinx.com. 


May 23-24 AC Developers Conference 2000 Santa Clara,CA 


June 5-7 37th Design Automation Conference — Los Angeles, CA 
June 21-23 WITI Technology Summit 2000 Santa Clara,CA 
July 24-28 NSREC 2000 Reno, NV 

Sept 6-7 Embedded Internet Conference 2000 San Jjose, CA 
Sept 26-28 MAPLD 2000 Laurel,M D 

Oct 17-18 NCF / InfoVision 2000 Chicago, IL 

Oct 18-20 Frontiers in Education 2000 Kansas City, MI 


European Shows: Andrea Fionda at: andrea. 
fionda@xilinx.com. 


Japanese Shows: Tetsuo Souyama at: tetsuo. 
souyama@xilinx.com 


SouthEast Asian Shows: Mary Leung at: mary. 
leung@xilinx.com 





co 


Continued on page 62. 


Go to the Xilinx web site to get the latest product information: 
http://www.xilinx.com/products/products.htm 


Development 


stem 


ilinx offers a variety of development system 





solutions, enabling the design and imple- 





mentation of Xilinx Programmable Logic 
devices. These development systems combine the 
industry’s fastest place and route technology, with a 
flexible and easy to use graphical interface to help you 
achieve the best possible designs within your project 
schedule, regardless of your experience level. 





Xilinx Alliance Series Software —AL ANCE 
htto://www.xilinx.com/products/alliance.htm & ~ = - o 
i =) 


The Alliance Series development sys- 


ty 


tems are designed for customers who have made an 


investment in a customized EDA environment. The 
Xilinx Alliance Series software integrates into these 
environments by leveraging open systems standards, 
Interfaces, and formats such as EDIF, SDF, VHDL, 
VITAL/ Verilog, and STAMP. Combining the strengths 
of our EDA partners’ tools with our advanced imple- 
mentation features gives you the ultimate in flexibility 
and design performance. FOUNDATION 





Sens Steve 


Xilinx Foundation Series Software 
htto://www.xilinx.com/products/found.htm 





The Foundation Series development systems are 
designed for customer’s who are interested in pur- 
chasing a complete, ready-to-use design solution for 
all of their programmable logic needs. Xilinx 
Foundation Series solutions enable both new and 
experienced programmable logic designers to achieve 
handcrafted results automatically, through push-but- 
ton design flows. Foundation Series solutions support 
schematic-only, HDL-only, and mixed-level design 
flows by seamlessly integrating some of the industry’s 


best EDA tools. . 
ModelSim.. 


ModelSim Xilinx Edition 
http://www.xilinx.com/products/softw are/mxe.htm 


The ModelSim Xilinx Edition (XE) simulator is a com- 
plete HDL simulation environment, optimized for use 
In verifying Xilinx programmable logic designs. 
ModelSim XE enables designers to verify the source 
code (VHDL and Verilog), as well as the functional 
and timing models of their design using a common 
“self-checking” testbench. ModelSim XE provides a 


olutions 


powerful first step into the world of HDL simulation 
with capacity and performance designed for the verifi- 
cation of the Xilinx XC9500 CPLD and Spartan series 
FPGA devices as well as lower-density XC4000 and 
Virtex series FPGAS. 


ModelSim XE is most valuable for customers who 
understand the benefits of VHDL or Verilog simula- 
tion, and are looking for a cost-effective solution for 
low-density programmable logic design. It is available 
in both VHDL and Verilog versions. ModelSim XE may 
only be used with Xilinx v2.1i development systems 
and later. Xilinx sells the ModelSim XE products as 
options to any of its development systems. 


CPLD Web-powered Software Solutions 


The Xilinx CPLD Web-powered Software Solutions 
offer designers the flexibility to do CPLD design evalu- 
ation and fitting on-line or on their desktop. The 
WebFITTER is an on-line device fitting and evaluation 
tool which accepts VHDL, Verilog, ABEL, or netlist 
files. The WebPACK downloadable desktop solutions 
offer free CPLD software modules from ABEL and HDL 
synthesis to device fitting and JTAG programming. 


WebFITTER 4. 
http://www.xilinx.com/sxpresso/webfitter.htm vou eR 
The Xilinx WebFITTER is a free, Web-based CPLD 
design evaluation and fitting software tool that allows 
system designers to target their designs using the 
industry’s best CPLDs, the XC9500 Series and the 
CoolRunner Series, on the latest version of Xilinx soft- 


ware and get their results and pricing in minutes. 


WebPACK 
http://www.xilinx.com/sxpresso/webpack.htm 





The Xilinx WebPACK contains free downloadable soft- 
ware solutions for Xilinx XC9500 and CoolRunner 
Series CPLDs. Each solution provides a simple and 
intuitive design environment for any Xilinx CPLD fam- 
ily. The WebPACK is a collection of three design suites: 
design entry, device fitting, and programming. These 
tools can be downloaded and used individually or, 
when installed together, become an integrated design 
environment for Xilinx CPLDs. #: 
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